BABYL OPTIONS:
Version: 5
Labels:
Note:   This is the header of an rmail file.
Note:   If you are seeing it in rmail,
Note:    it means the file has no messages in it.

1,,
Summary-line: 21-Dec  treese@CRL.DEC.COM         #Test message
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA19550; Thu, 21 Dec 89 16:12:23 EST
Received: from CRL.DEC.COM by ATHENA.MIT.EDU with SMTP
	id AA01441; Thu, 21 Dec 89 16:12:26 EST
Received: by crl.dec.com; id AA08920; Thu, 21 Dec 89 16:09:57 -0500
Date: Thu, 21 Dec 89 16:09:55 EST
From: treese@CRL.DEC.COM
Message-Id: <8912212109.AA04308@cirocco.crl.dec.com>
To: auth-api-ext@CRL.DEC.COM
Subject: Test message
Cc: treese@CRL.DEC.COM

*** EOOH ***
Date: Thu, 21 Dec 89 16:09:55 EST
From: treese@CRL.DEC.COM
To: auth-api-ext@CRL.DEC.COM
Subject: Test message
Cc: treese@CRL.DEC.COM


This message is to notify you that the mailing list "auth-api-ext@crl.dec.com"
(for Internet users, "crl::auth-api-ext" for DECnet users) has been set up
with the participants from this morning's meeting on it.

Please let me know if you do not wish to be on the list.

	- Win

1,answered,,
Summary-line: 21-Dec  treese@CRL.DEC.COM         #internal DEC list
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA19561; Thu, 21 Dec 89 16:12:52 EST
Received: from CRL.DEC.COM by ATHENA.MIT.EDU with SMTP
	id AA01461; Thu, 21 Dec 89 16:13:02 EST
Received: by crl.dec.com; id AA08943; Thu, 21 Dec 89 16:12:34 -0500
Date: Thu, 21 Dec 89 16:12:32 EST
From: treese@CRL.DEC.COM
Message-Id: <8912212112.AA04316@cirocco.crl.dec.com>
To: jtkohl@ATHENA.MIT.EDU
Subject: internal DEC list
Cc: treese@CRL.DEC.COM

*** EOOH ***
Date: Thu, 21 Dec 89 16:12:32 EST
From: treese@CRL.DEC.COM
To: jtkohl@ATHENA.MIT.EDU
Subject: internal DEC list
Cc: treese@CRL.DEC.COM


John,

For convenience, I split the auth-api-ext list into two pieces, one DEC
and the other one not-DEC.  The DEC one may get used for internal discussions;
do you want to be included on it?

	- Win

1,,
Summary-line: 20-Dec  bbrown@DECVAX.DEC.COM      #Apollo request wrt Auth API
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA11290; Wed, 20 Dec 89 11:15:09 EST
Received: from decvax.dec.com by ATHENA.MIT.EDU with SMTP
	id AA06755; Wed, 20 Dec 89 11:15:15 EST
Received: by decvax.dec.com (5.57/v2.4)
	id AA28354; Wed, 20 Dec 89 11:10:00 -0500
Received: by abyss.zk3.dec.com (5.57/dv.5.yp)
	id AA04613; Wed, 20 Dec 89 11:14:34 -0500
Message-Id: <8912201614.AA04613@abyss.zk3.dec.com>
To: steiner@OSF.ORG
Cc: angel%msbis1.enet@DECWRL.DEC.COM, barlow%decwet.enet@DECWRL.DEC.COM,
        bbrown@DECVAX.DEC.COM, kaufman@DECVAX.DEC.COM, lawler@DECVAX.DEC.COM,
        linn%ultra.enet@DECWRL.DEC.COM, palka%prfect.enet@DECWRL.DEC.COM,
        pitkin%took.enet@DECWRL.DEC.COM, schimpf%took.enet@DECWRL.DEC.COM,
        sudama%took.enet@DECWRL.DEC.COM, goldstein%star.enet@DECWRL.DEC.COM,
        williams@DECVAX.DEC.COM, jtkohl@ATHENA.MIT.EDU, treese@CRL.DEC.COM
Subject: Apollo request wrt Auth API
Date: Wed, 20 Dec 89 11:14:31 EST
From: bbrown@DECVAX.DEC.COM

*** EOOH ***
To: steiner@OSF.ORG
Cc: angel%msbis1.enet@DECWRL.DEC.COM, barlow%decwet.enet@DECWRL.DEC.COM,
        bbrown@DECVAX.DEC.COM, kaufman@DECVAX.DEC.COM, lawler@DECVAX.DEC.COM,
        linn%ultra.enet@DECWRL.DEC.COM, palka%prfect.enet@DECWRL.DEC.COM,
        pitkin%took.enet@DECWRL.DEC.COM, schimpf%took.enet@DECWRL.DEC.COM,
        sudama%took.enet@DECWRL.DEC.COM, goldstein%star.enet@DECWRL.DEC.COM,
        williams@DECVAX.DEC.COM, jtkohl@ATHENA.MIT.EDU, treese@CRL.DEC.COM
Subject: Apollo request wrt Auth API
Date: Wed, 20 Dec 89 11:14:31 EST
From: bbrown@DECVAX.DEC.COM

Hi,
	Apollo folk want to come to the meeting, see the below.  John
Williams and I(Ultrix/OSG) have no objections and neither does John
Kohl(Athena).  Do any of you?
	Because of the time limitations, I will assume that Brian
Schimpf will officially speak for one DEC group/project, Charlie
Kaufman will speak for another DEC group/project, and Jennifer Steiner
will speak for OSF.   Everyone is invited to respond to the list above
or along private channels.  Please understand that the meeting may be
restricted for now because of what DEC wishes to discuss.

							Bill

p.s.  Bill Sommerfeld was one of the early and primary developers of Kerberos.


------- Forwarded Message

Return-Path: sommerfeld@apollo.com
Received: by decvax.dec.com (5.57/v2.4)
	id AA08208; Tue, 19 Dec 89 16:45:13 -0500
Received: from [15.20.32.112] by amway id <AA19238@amway> Tue, 19 Dec
89 16:47:16 EST    
Received: by xuucp.ch.apollo.com id <AA02482@xuucp.ch.apollo.com>; Tue,
19 Dec 89 16:39:26 EST
Message-Id: <8912192139.AA02482@xuucp.ch.apollo.com>
Received: by daphne  id AA03340; Tue, 19 Dec 89 15:36:47 EST    
Received: by icarus.apollo.hp.com id <AA01758@icarus.apollo.hp.com>;
Tue, 19 Dec 89 15:36:43 EST    
Date: Tue, 19 Dec 89 15:36:43 EST
From: sommerfeld@apollo.com (Bill Sommerfeld)
To: bbrown@decvax
Cc: jtkohl@athena.mit.edu, Joe Pato <pato@apollo.com>
Subject: Authentication API meeting at CRL on Thursday Morning.

I got the announcement of this meeting from John Kohl through a
mailing list at Athena that I'm on.

Joe Pato and I of Apollo[*] have been doing some work in this area in
relation to the DEcorum OSF submission and NCS.  We are interested in
attending.  Both of us are apollo employees; I spend part of my time
as a visiting engineer at MIT/Athena.

If it's possible for either or both of us to attend, let me know via
either electronic mail or phone ASAP.  Thanks in advance.

				Bill Sommerfeld
				sommerfeld@apollo.com
				(508) 256-6600 x2056

[*] "The Apollo Systems Division of Hewlett Packard"

------- End of Forwarded Message


1,,
Summary-line:  2-Jan  3-5491.  02-Jan-1990 1010  #Working draft API proposal, follow-up to 21 December meeting
Received: by crltrx.crl.dec.com; id AA04071; Tue, 2 Jan 90 10:44:19 -0500
Received: by easynet.crl.dec.com; id AA07164; Tue, 2 Jan 90 10:42:44 -0500
Date: Tue, 2 Jan 90 10:42:43 -0500
Message-Id: <9001021542.AA07164@easynet.crl.dec.com>
From: linn@bombe.enet (John Linn. 508-264-5491. DTN 293-5491.  02-Jan-1990 1010)
To: auth-api-ext@crl.enet
Cc: KAUFMAN@KIBITZ.enet, LINN
Subject: Working draft API proposal, follow-up to 21 December meeting

*** EOOH ***
Date: Tue, 2 Jan 90 10:42:43 -0500
From: linn@bombe.enet (John Linn. 508-264-5491. DTN 293-5491.  02-Jan-1990 1010)
To: auth-api-ext@crl.enet
Cc: KAUFMAN@KIBITZ.enet, LINN
Subject: Working draft API proposal, follow-up to 21 December meeting

This message summarizes a provisional API proposal, close to that which Charlie
Kaufman presented at the 21 December meeting but reflecting some later
reconsideration.  Some open issues remain; we're presenting this to the group
as a springboard for further discussion, not to declare a fait accompli.

--Charlie Kaufman and John Linn

-------------------------

The following is a proposal for organization of a generic interface to a data
origin authentication service, which can accomodate either Kerberos or
public-key cryptography as underlying technologies with minimal impact on
calling applications.  This interface will not exploit the full capabilities of
either system, but will meet the authentication needs of the majority of
applications.  Applications written to this interface will be "portable".   The
interface is independent of the communications protocol suite(s) with which it
is used, and relieves applications of the burdens attendant to managing control
communications with authentication servers.

This service provides mechanisms to sign messages, to verify signatures, and to
request delegation of access rights from an initiator to a target of
authentication information.  Through use of the service, initiating principals
securely demonstrate their identities to targets in a distributed computing
environment. The service is independent of underlying protocols and addressing
structure, although callers will in some cases provide protocol-specific
information as input to the interface.   The authentication service inserts
timestamps into output authentication messages and maintains (within a
time-limited window) a cache of input authentication messages in order to
provide a level of replay detection.  Support for the replay detection cache
is a local implementation issue at a target system, and may be omitted if this
security feature is not required at a particular system.

The service's operations depend on data structures called credentials. The
contents of credentials structures will vary depending on the underlying
authentication type in use, but their internal semantics are opaque from the
viewpoint of callers.  Since credentials structures contain sensitive data,
local measures are expected to be used to secure those structures against
unauthorized access. Callers are expected to determine, whether from implicitly
known context, consultation of a naming service, or other means, the
authentication type which is appropriate for a particular target so that the
appropriate credential information will be used to formulate suitable message
elements for that target.  The proposal described below assumes a single
credentials structure per caller, even if that caller uses multiple
authentication types in order to authenticate to different peers; an
alternative approach would represent each authentication type employed by a
caller with a separate credentials structure.

Proposed interfaces:

	Login(myname,mypassword,expiration,auth_types) returns (credentials)

		myname is the name of the entity logging in
		mypassword is its password
		expiration is the desired expiration interval for the ticket
		auth_types is a list of underlying authentication types for
		  which corresponding tickets and session keys should be 
		  returned in credentials

	returns:

		credentials contains the name of the authenticated entity,
		  includes a ticket structure (or structures, if multiple
		  auth_types are requested) which can be presented to
		  assert the entity's identity, and provides
		  a cryptographic session key (keys, if multiple auth_types)
                  whose use serves to demonstrate 
		  the entity's authorized ownership of the ticket

The Login() interface provides a standardized means for an entity to
demonstrate its identity through presentation of a password and to receive
appropriate authentication credentials.  Its definition and inclusion is not
intended to preclude use of other authentication techniques (e.g., smart
cards) and associated interfaces providing interchangeable credentials. The
returned ticket will be presented either to an authentication server  or
directly to an application's peer, depending on underlying authentication
type; significantly, in either case, the returned ticket is independent
of the particular peers to which the authenticated entity will need to
demonstrate its identity.

	Sign(message,credentials,target,deleg_flag,auth_type)
		returns (repeating_context,nonrepeating_context)

		message is an application-specific block of bits to be signed
		credentials is the data returned by Login (or Verify)
		target is the name of the intended recipient of the
			message
		deleg_flag is set if delegation to the target should be
			piggy-backed on this message
		auth_type indicates the underlying authentication type 
			appropriate for the target

	returns:
		repeating_context names the signer and incorporates a
		  suitable ticket to authenticate the signer to the target
		nonrepeating_context contains a transformation of the 
                  input message and a timestamp, performed with the session key 
                  corresponding to the ticket carried in repeating_context

Specification of an auth_type which was not included in the signer's initial
Login() may result in an error, unless credential conversion functions are
available.  The returned repeating_context must be accessible to the recipient
in order to successfully verify any message signed with the current
credentials, but can often be cached by the recipient so as to avoid the need
for retransmission of this data during an ongoing association.  The (normally
smaller) nonrepeating_context is message-specific, so must be transferred with
each signed message.

	Verify(message,repeating_context,nonrepeating_context,
               target_credentials)
	    returns (status,signing_time,originator_data,credentials,auth_type)

		message is the block of bits supposedly signed
		repeating_context is as returned by Sign(), possibly
	    	  recovered from a recipient-maintained cache
		nonrepeating_context is as returned by Sign()
		target_credentials is a credentials structure containing
		  keys associated with the target

	returns:

		status = good | bad | duplicate | good except expired | others?	
		signing_time corresponds to the timestamp inserted by Sign()
		originator_data identifies the principal who signed the
		  message (TBD whether the principal's name is returned
                  directly or whether a structure is returned from which the
		  name can be extracted by other routines)
		credentials is returned only as a result of a valid verified
		  message which delegated to the target, processed
	 	  by a Verify() call with valid input target_credentials;
                  the returned credentials can be used by the target 
                  in further calls to Sign.
		auth_type indicates the underlying authentication type
		  used in the Verify() operation

A cache of received timestamps extending from the current time to a (locally
configured) interval before the current time is maintained in conjunction with
Verify().  (An implicit tradeoff exists between timestamp resolution and
possible resulting cache size.) Status "good" is returned for a  message with a
valid signature and a non-duplicate timestamp within the window; status "bad"
is returned for a message with an invalid signature; status "duplicate" is
returned for a message with a valid signature but a timestamp which duplicates
an entry recorded in the timestamp cache; status "good except expired" is
returned for a message with a valid signature but a timestamp outside the
cache's time window.


1, filed,,
Summary-line:  3-Jan  an Schimpf - DTN 226-5292  #Minutes of December 21 meeting
Received: by crltrx.crl.dec.com; id AA04966; Wed, 3 Jan 90 10:00:16 -0500
Received: by easynet.crl.dec.com; id AA08636; Wed, 3 Jan 90 09:58:19 -0500
Date: Wed, 3 Jan 90 09:58:18 -0500
Message-Id: <9001031458.AA08636@easynet.crl.dec.com>
From: schimpf@took.enet (Brian Schimpf - DTN 226-5292)
To: auth-api-ext@crl.enet
Cc: SCHIMPF
Subject: Minutes of December 21 meeting

*** EOOH ***
Date: Wed, 3 Jan 90 09:58:18 -0500
From: schimpf@took.enet (Brian Schimpf - DTN 226-5292)
To: auth-api-ext@crl.enet
Cc: SCHIMPF
Subject: Minutes of December 21 meeting


+---+---+---+---+---+---+---+
| d | i | g | i | t | a | l |     I N T E R O F F I C E   M E M O
+---+---+---+---+---+---+---+


                                   Date:  January 3, 1990
                                   From:  Brian C. Schimpf
                                   Dept:  Distributed Processing Engineering
                                   Ext:   226-5292
                                   Decnet:  TOOK::SCHIMPF
                                   Mail Stop:  LKG2-2/Z7

To:	  Attendees

Subject:  Meeting to discuss common authentication interface

	A meeting was held on Thursday, December 21, 1989 at Digital's 
Cambridge Research Lab.  The goal of the meeting was to begin some dialog
regarding the definition of a common application programming interface for
distributed authentication.  Attendees at the meeting were:

	Bill Brown		Digital (ULTRIX)
	Andy Goldstein		Digital (VMS)
	Brad Johnson		OSF
	Charlie Kaufman		Digital (Networks and Communications)
	John Kohl		MIT/Project Athena
	Butler Lampson		Digital (CRL)
	Jane Lawler		Digital (ULTRIX)
	John Linn		Digital (Secure Systems)
	Joe Pato		HP/Apollo
	Richard Pitkin		Digital (Distributed Processing)
	Jon Rochlis		MIT/Project Athena
	Jeff Schiller		MIT/Project Athena
	Brian Schimpf		Digital (Distributed Processing)
	Bill Sommerfeld		HP/Apollo
	Jennifer Steiner	OSF
	Win Treese		Digital (CRL)
	John Williams		Digital (ULTRIX)

The meeting began with each participant having a chance to briefly introduce 
himself/herself, state the organization (in some cases multiple organizations) 
s/he represented and indicate his or her interest in the topic.  Next, Bill
Brown presented a summary of Digital's goals for the discussion, which were
to define an API for authentication that would be independent of:

   - protocol suite,
   - authentication service,
   - naming structure,
   - addressing structure, and
   - cryptographic method.

Since Kerberos exists today and is coming into widespread use it clearly is one
of the authentication services this interface must accomodate.  Other possible
services have been or are being defined as well.  Charlie Kaufman pointed out
that the emphasis of the discussion should be on application portability.  True
interoperability is a long-term goal but some aspects of interoperability may
be beyond the scope of this immediate discussion.

	Jeff Schilling offered his opinion that the two key problems in 
defining a common interface seem to be:

   1) naming, and
   2) how to allow applications to select the authentication service.

This led to a discussion of whether the application needs to be aware of which
authentication service it is using and to select the proper one.  I'm not sure
this discussion reached a clear conclusion.

	The naming discussion addressed the need for two sorts of names.  One
would be a name meaningful in the application's "local" context, which could
still imply multiple nodes in a distributed system.  The other sort of name
would be a global name, which the discussion tended to refer to as a "network
name."  The discussion centered on which name(s) should be included in the API.
The conclusion was that various applications will probably need both.  The
global name clearly has to be included in the interface.  The local name can
either also be included or the application can have access to a service to
accomplish a mapping from the global name to the local name.  This service
could be part of the authentication API but doesn't necessarily have to be and
this issue probably needs further discussion.  John Williams asked if X.500 
was the right model for the global name and there seemed to be general 
agreement that this was the correct approach.

	The question was raised as to whether the API being discussed should
be the minimal intersection of the various capabilities of all the applicable
authentication services or should it be the full union of those capabilities?
The intersection approach makes portability very clear to the application
programmer but might require the creation of awkward alternative mechanisms
to get at other capabilities provided by a given implementation but not in
the intersection set.  Richard Pitkin suggested that the focus should be on
what applications really need in terms of authentication.  This will be a key
issue.

	Charlie Kaufman offered a general model for the interface that consists
of three major calls, which he called "login" (or "create authentication
context,") "sign," and "verify."  Charlie offered to write up his model for
distribution and discussion at a future meeting.  Others were invited to do 
the same.

	There was agreement to have another meeting to discuss the next level
of detail of the interface, probably with fewer attendees, with the attitude
that smaller meetings tend to be more productive.  The date of January 9 was
discussed.  Please let me know if that date is good or not good for you if you
would like to attend the next meeting.  There were several items brough up that 
relate to timing of this discussion.

  * Active work is currently being done on version 5 of Kerberos.  John Kohl
    stated that it is hoped that the "grunge work" would be done by the end
    of January.  (The definition of the details of "grunge" and the correct
    spelling are left as exercises for the reader.  :-)  )

  * BSD 4.4 will incorporate Kerberos.  The timeframe for 4.4 is a little up
    in the air at present but they seem to be shooting for having test versions
    out this summer.  If V5 of Kerberos is ready in time it will be included in
    BSD 4.4.  If not, V4 will be included.

  * OSF will be making its decisions about the distributed computing interfaces,
    including authentication, during the second quarter of 1990 (March to June.)

Win Treese offered to host the second meeting as the location in Cambridge seems
most convenient to all.  If the date of January 9 is workable a further notice
will be sent out soon.


                            [End of Minutes]


1,,
Summary-line:  3-Jan  Bill Sommerfeld            #a modified proposal.
Received: by crltrx.crl.dec.com; id AA06541; Wed, 3 Jan 90 19:23:21 -0500
Received: by crl.dec.com; id AA06593; Wed, 3 Jan 90 19:21:17 -0500
Received: from [15.20.32.112] by amway.apollo.com id <AA29714@amway.apollo.com> Wed, 3 Jan 90 19:21:06 EST    
Received: by xuucp.ch.apollo.com id <AA07428@xuucp.ch.apollo.com>; Wed, 3 Jan 90 18:32:12 EST
Message-Id: <9001032332.AA07428@xuucp.ch.apollo.com>
Received: by daphne  id AA26431; Wed, 3 Jan 90 18:10:56 EST    
Received: by icarus.apollo.hp.com id <AA01246@icarus.apollo.hp.com>; Wed, 3 Jan 90 18:10:45 EST    
Date: Wed, 3 Jan 90 18:10:45 EST
From: sommerfeld@apollo.com (Bill Sommerfeld)
To: auth-api-ext
Subject: a modified proposal.

*** EOOH ***
Date: Wed, 3 Jan 90 18:10:45 EST
From: sommerfeld@apollo.com (Bill Sommerfeld)
To: auth-api-ext
Subject: a modified proposal.

This is substantially more complicated than the three operation
version, but it seems to be more realistic and appears to be usable
for real programs.

Type and operation names are preliminary and should come from a
restricted namespace of some sort.
------
Data types:

"credential": contains the "identity" of the user in some way 
	(secret key/link to smart card/pointer to ticket cache).

"context": per-connection opaque structure holding things like session
keys, etc; this appears to be the "repeating context" referred to before.

"name": a principal name.  Probably a character string.

"timestamp": an absolute time.

"deltatime": a length of time, used for specifying lifetimes.

"endpoint": a protocol endpoint (something like a "struct sockaddr" 
			         in the BSD socket interface).

"message": a counted octet string.  This will probably have to be
	passed as a (address, length) pair.

------
Operations:

a) Ways of getting credentials:

Login(name myname, bytestring mypassword, deltatime expiration, auth_types) returns (credential)

Given a login name and a password, do whatever is necessary to log the
user in.

GetDefClientCredential () returns (credential, name)

GetDefServerCredential () returns (credential, name)

b) Ways of getting rid of credentials:

DestroyCredential(credential)

Destroy any permanent state of the credential (e.g., flush the ticket
cache).

FreeCredential(credential)

Remove the credential from this address space only, in an attempt to
reduce the exposure of encryption keys.

c) Setting up associations:

CreateAssoc (credential me, name othername, endpoint otherloc,
	deltatime expiration)
	returns (context, setup_message)

	"othername" is the principal name of the other end.
	"otherloc" is the protocol address of the other end.

	The "context" is a local data structure which contains
	"connection information" such as the session key used; it can
	be passed to "Sign" and/or "Verify".

	"deltatime" is a *lower* bound on the lifespan of the
	association.

	The "setup_message" is delivered to "othername" some how or
	other.

CreateAssocFromPassword (name myname, bytestring mypassword, 
	name othername, endpoint otherloc, deltatime expiration)
	returns (context, setup_message)

        A cross between CreateAssoc and Login.  The association is created directly
        from the password, without leaving behind a (visible) credentials structure.

VerifyAssoc (credential me, setup_message, endpoint otherloc)
		returns (errorcode, context, client info)

	This is called at the reciever's end, and reconstitutes the "context" 
	from the "setup_message".

	The returned "context" can be passed to "Sign" and/or "Verify".

	"client info" includes things such as a client name, additional 
	privelege info, etc.; 

DestroyAssoc(context)

	Destroys an association.

d) Signing messages, once association is set up:

SignatureSize(context)
	Returns the size in bytes of a signature; allows the
application to choose a packet size which is as large as possible
while avoiding fragmentation, etc.

This is an issue for datagram protocols (like NCS) which do their own
fragmentation, and want to fit as much as possible into each datagram
without triggering lower-level fragmentation.

Sign (context, message) returns (signature)

	Given the "context" and a message, "sign" it in some way.
	"signature" is at most SignatureSize(context) bytes long.

Verify (context, message, signature) returns (errorcode) 

	Given the "context" and a signed message recieved over the
	wire, make an integrity check of the message and return a 
	"thumbs-up/thumbs-down" indication.

---
Providing the following would be genuinely useful, but would impede export:

Encrypt (context, message) returns (encrypted message)

Decrypt (context, encrypted message) returns (decrypted message)

EncryptionSize(context)

e) delegation/forwarding:

ForwardCred(context, credentials, endpoint) returns (message)

ReceiveCred(context, mycredentials, endpoint, message) returns (new_credentials)

This is a separate operation, because to forward credentials (and
recieve forwarded credentials) is an inherently "dangerous" operation.
----------------
Some issues which are of some importance; none of these are hard to
deal with:

	- the "client info" structure needs to be defined.

	- credentials can exist soley in the address space of a user's
process or also in an object which is accessible from multiple
processes (e.g., a "ticket file" or in-kernel "ticket cache").

A server which runs as a single address space would have no need to
put the credentials anywhere else, and probably shouldn't put them
outside its address space.

Perhaps Login should take a flag to indicate this.

	- keys vs. passwords.

	In kerberos, the encryption key is a one-way function of the
user's password.  Current SOP is for servers to store the fixed-size
encryption key rather than the password; to support this, there would
have to be another set of routines which take "keys" rather than
"passwords".

	- Error returns:

	Nothing has been said about error returns to applications, so
I'll put in my two cents worth:

	Authentication systems are designed to fail when things go
wrong; this makes debugging transient failures when writing
applications very painful, especially when the same error code is
returned from forty different points in the authentication code.

	Whatever error return mechanism is used should not throw away
information or collapse several different but related authentication
protocol errors into a single generic error.

-------

Comments?

				Bill Sommerfeld
				sommerfeld@apollo.hp.com
				(508) 256-6600 x2056


1,,
Summary-line:  3-Jan  Joe Pato                   #Re: Working draft API proposal, follow-up to 21 December meeting
Received: by crltrx.crl.dec.com; id AA00989; Thu, 4 Jan 90 04:36:48 -0500
Received: by crl.dec.com; id AA04535; Wed, 3 Jan 90 11:38:36 -0500
Received: from [15.20.32.112] by amway.apollo.com id <AA28701@amway.apollo.com> Wed, 3 Jan 90 11:37:56 EST    
Received: by xuucp.ch.apollo.com id <AA04479@xuucp.ch.apollo.com>; Wed, 3 Jan 90 11:28:04 EST
Message-Id: <9001031628.AA04479@xuucp.ch.apollo.com>
Received: by daphne  id AA21199; Wed, 3 Jan 90 10:32:54 EST    
Received: by munin.apollo.hp.com id <AA01419@munin.apollo.hp.com>; Wed, 3 Jan 90 10:32:35 EST    
From: pato@apollo.com (Joe Pato)
Date: Wed, 3 Jan 90 10:32:34 EST
Subject: Re: Working draft API proposal, follow-up to 21 December meeting
To: linn@bombe.enet (John Linn. 508-264-5491. DTN 293-5491.  02-Jan-1990 1010)
Cc: auth-api-ext, KAUFMAN@KIBITZ.enet, LINN
In-Reply-To: linn@bombe.enet.dec.com (John Linn. 508-264-5491. DTN 293-5491.  02-Jan-1990 1010), tue, 2 jan 90 10:52:04

*** EOOH ***
From: pato@apollo.com (Joe Pato)
Date: Wed, 3 Jan 90 10:32:34 EST
Subject: Re: Working draft API proposal, follow-up to 21 December meeting
To: linn@bombe.enet (John Linn. 508-264-5491. DTN 293-5491.  02-Jan-1990 1010)
Cc: auth-api-ext, KAUFMAN@KIBITZ.enet, LINN
In-Reply-To: linn@bombe.enet.dec.com (John Linn. 508-264-5491. DTN 293-5491.  02-Jan-1990 1010), tue, 2 jan 90 10:52:04

I stepped out of the meeting briefly during the discussion of this interface,
so my questions may have already been discussed...

1) I am concerned that a generic API consisting only of: 

    	Login(myname,mypassword,expiration,auth_types)
    
    	Sign(message,credentials,target,deleg_flag,auth_type)

    	Verify(message,repeating_context,nonrepeating_context,
                   target_credentials)

Does not cover the case of applications that do not (and maybe should not) have
access to the principal's password.  I think that, minimally, we need to add an
operation to access potentially cached credentials for the initiator of the
remote operation.  Something like:

        GetCredentials(myname, expiration, auth_type)
            returns: (credentials)

Unfortunately, the problem with this is that the server can now not
differentiate initiators that possess a primary authenticator (e.g., password)
from those that have access to cached information.  This can be resolved
allowing credentials returned by GetCredentials to be tagged as 'less-pure'
than credentials returned by Login.  (They wouldn't always be tagged this way. 
For example, credentials extracted from a smart-card are always 'pure' unless
the card is protected by a PIN.)  Repeating_context data generated from a
credential would inherit the purity label from the credential.  Purity
information would then be extractable in Verify or in the operation that
extracts the principal's name (really a PAC - Privilege Attribute Certificate).

GetCredentials fails if the local system does not possess cached credential
information (e.g., In a Kerberos world it would fail if you did not have a TGT
in the ticket cache) or if the cached credential does not meet the expiration
requirements (e.g., the TGT is only valid for another 20 minutes and you
request a credential for the next 24 hours).  The application can recover from
these failures by invoking Login.

2) I'd like to be able to control the re-use of a repeating_context in calls to
Sign.  Currently there is no input parameter that associates an existing
repeating_context with this Sign event - this means that an implementation
would have to guess when it is appropriate to reuse potentially cached tickets.

3) Presumably Verify yields a message that is intelligible to the recipient. 
This isn't clear from the write-up.  It would also be nice if Verify took a
processed repeating_context as a parameter rather than requiring that
information be recalculated from the the initiator supplied
repeating_context and the target_credentials.

Bill Sommerfeld is working on a modified proposal that we'll either mail before
or bring to the meeting next week.

 Joe Pato
 Apollo Computer            A Subsidiary of Hewlett-Packard
 NSFNET: pato@apollo.com    UUCP: ...{attunix,uw-beaver,brunix}!apollo!pato
-------


1,,
Summary-line:  4-Jan  3-5491.  04-Jan-1990 0949  #Re: Working draft API proposal, follow-up to 21 December meeting
Received: by crltrx.crl.dec.com; id AA06530; Thu, 4 Jan 90 11:22:18 -0500
Received: by easynet.crl.dec.com; id AA00608; Thu, 4 Jan 90 11:16:45 -0500
Date: Thu, 4 Jan 90 11:16:41 -0500
Message-Id: <9001041616.AA00608@easynet.crl.dec.com>
From: linn@ultra.enet (John Linn. 508-264-5491. DTN 293-5491.  04-Jan-1990 0949)
To: "pato@apollo.com"@CRL.enet
Cc: AUTH-API-EXT@CRL.enet, LINN
Subject: Re: Working draft API proposal, follow-up to 21 December meeting

*** EOOH ***
Date: Thu, 4 Jan 90 11:16:41 -0500
From: linn@ultra.enet (John Linn. 508-264-5491. DTN 293-5491.  04-Jan-1990 0949)
To: "pato@apollo.com"@CRL.enet
Cc: AUTH-API-EXT@CRL.enet, LINN
Subject: Re: Working draft API proposal, follow-up to 21 December meeting

Joe,

Thanks for the comments. Some thoughts on one of your topics:

>1) I am concerned that a generic API consisting only of: 
> 
>    	Login(myname,mypassword,expiration,auth_types)
>    
>    	Sign(message,credentials,target,deleg_flag,auth_type)
> 
>    	Verify(message,repeating_context,nonrepeating_context,
>                   target_credentials)
> 
>Does not cover the case of applications that do not (and maybe should not) have
>access to the principal's password.  I think that, minimally, we need to add an
>operation to access potentially cached credentials for the initiator of the
>remote operation.  

There was no intent to impose a constraint that the caller of Login() on behalf
of a user need be the same application which subsequently calls Sign() or
Verify() with the credentials output from Login().  As I see it, the ordinary
case will be one where Login() is invoked by a hook in the same code path
through which a user authenticates himself/herself to the local operating
system, and subsequently (mediated by local means) the resulting credentials
are made available for use by applications instantiated with the user's access
rights.

>Something like:
> 
>        GetCredentials(myname, expiration, auth_type)
>            returns: (credentials)
> 
>Unfortunately, the problem with this is that the server can now not
>differentiate initiators that possess a primary authenticator (e.g., password)
>from those that have access to cached information.  This can be resolved
>allowing credentials returned by GetCredentials to be tagged as 'less-pure'
>than credentials returned by Login.  (They wouldn't always be tagged this way. 
>For example, credentials extracted from a smart-card are always 'pure' unless
>the card is protected by a PIN.)  Repeating_context data generated from a
>credential would inherit the purity label from the credential.  Purity
>information would then be extractable in Verify or in the operation that
>extracts the principal's name (really a PAC - Privilege Attribute Certificate).

>GetCredentials fails if the local system does not possess cached credential
>information (e.g., In a Kerberos world it would fail if you did not have a TGT
>in the ticket cache) or if the cached credential does not meet the expiration
>requirements (e.g., the TGT is only valid for another 20 minutes and you
>request a credential for the next 24 hours).  The application can recover from
>these failures by invoking Login.
 
Some sort of (possibly local) interface is needed for a Sign()ing process to
get at stored credentials, and expiration or non-existence error checks would
be appropriate in conjunction with this operation.  I'm not so sure about the
purity designation concept. I assume the need to trust correctly-applied local
mechanisms to preclude use of credential data by entities unrelated to the
corresponding Login(); such mediation appears intrinsic to an authentication
architecture which discriminates among principals located on the same computer.  
Is the goal of the purity designation mechanism to allow targets of access
attempts to make particular resources accessible only to peer processes which
directly possess passwords or analogous quantities, as a means to compensate in
part for possible inadequate assurance in the local mediation mechanism?  This
measure might have the negative result of forcing users to expose their
passwords at multiple points within a system so that the processes they
initiate can get "better" (more widely accepted) forms of credentials.   I
think we could avoid trouble by keeping the interface between human-entered and
computer-interoperable forms of authentication data as close to the
human-computer interface as possible; is this inconsistent with your implicit
trust and/or assurance model?

--jl


1,,
Summary-line:  4-Jan  an Schimpf - DTN 226-5292  #Meeting on authentication API
Received: by crltrx.crl.dec.com; id AA07943; Thu, 4 Jan 90 13:23:28 -0500
Received: by easynet.crl.dec.com; id AA01000; Thu, 4 Jan 90 13:17:34 -0500
Date: Thu, 4 Jan 90 13:17:30 -0500
Message-Id: <9001041817.AA01000@easynet.crl.dec.com>
From: schimpf@took.enet (Brian Schimpf - DTN 226-5292)
To: auth-api-ext@crl.enet
Cc: SCHIMPF
Subject: Meeting on authentication API

*** EOOH ***
Date: Thu, 4 Jan 90 13:17:30 -0500
From: schimpf@took.enet (Brian Schimpf - DTN 226-5292)
To: auth-api-ext@crl.enet
Cc: SCHIMPF
Subject: Meeting on authentication API

	There appears to be interest in having another meeting to follow the
one held on December 21.  I am trying to confirm the logistics but I believe
it is safe to assume that it will be on Tuesday, January 9 from 10:00 to 12:00
at Digital's Cambridge Research Lab, i.e., same place, same time of day.  At
the last meeting we discussed holding such a meeting with a smaller group in
the hopes of getting some detailed work done.  I didn't want to get into a
position of establishing any policies about limiting attendance so we'll leave
that to each party's best judgement.  The intent is to have this be a working
meeting.  Results will be mailed to everyone who attended the first meeting.

Thanks,

Brian Schimpf


1,,
Summary-line:  4-Jan  Joe Pato                   #Re: Working draft API proposal, follow-up to 21 December meeting
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA02919; Thu, 4 Jan 90 14:21:16 EST
Received: from CRL.DEC.COM by ATHENA.MIT.EDU with SMTP
	id AA05370; Thu, 4 Jan 90 14:21:00 EST
Received: by crl.dec.com; id AA03046; Thu, 4 Jan 90 14:19:13 -0500
Received: by crltrx.crl.dec.com; id AA11075; Thu, 4 Jan 90 14:18:44 -0500
Received: by crltrx.crl.dec.com; id AA11060; Thu, 4 Jan 90 14:18:36 -0500
Received: by crl.dec.com; id AA02973; Thu, 4 Jan 90 14:11:30 -0500
Received: from [15.20.32.112] by amway.apollo.com id <AA00567@amway.apollo.com> Thu, 4 Jan 90 14:09:38 EST    
Received: by xuucp.ch.apollo.com id <AA11203@xuucp.ch.apollo.com>; Thu, 4 Jan 90 13:59:03 EST
Message-Id: <9001041859.AA11203@xuucp.ch.apollo.com>
Received: by daphne  id AA02400; Thu, 4 Jan 90 13:12:54 EST    
Received: by munin.apollo.hp.com id <AA01758@munin.apollo.hp.com>; Thu, 4 Jan 90 13:12:36 EST    
From: pato@APOLLO.COM (Joe Pato)
Date: Thu, 4 Jan 90 13:12:35 EST
Subject: Re: Working draft API proposal, follow-up to 21 December meeting
To: linn@ultra.enet.dec.com (John Linn. 508-264-5491. DTN 293-5491.  04-Jan-1990 0949)
Cc: AUTH-API-EXT@CRL.DEC.COM
In-Reply-To: linn@ultra.enet.dec.com (John Linn. 508-264-5491. DTN 293-5491.  04-Jan-1990 0949), thu, 4 jan 90 12:05:20

*** EOOH ***
From: pato@APOLLO.COM (Joe Pato)
Date: Thu, 4 Jan 90 13:12:35 EST
Subject: Re: Working draft API proposal, follow-up to 21 December meeting
To: linn@ultra.enet.dec.com (John Linn. 508-264-5491. DTN 293-5491.  04-Jan-1990 0949)
Cc: AUTH-API-EXT@CRL.DEC.COM
In-Reply-To: linn@ultra.enet.dec.com (John Linn. 508-264-5491. DTN 293-5491.  04-Jan-1990 0949), thu, 4 jan 90 12:05:20

John,

>   There was no intent to impose a constraint that the caller of Login() on behalf
>   of a user need be the same application which subsequently calls Sign() or
>   Verify() with the credentials output from Login().  As I see it, the ordinary
>   case will be one where Login() is invoked by a hook in the same code path
>   through which a user authenticates himself/herself to the local operating
>   system, and subsequently (mediated by local means) the resulting credentials
>   are made available for use by applications instantiated with the user's access
>   rights.

    I agree that the normal path is to acquire credentials through the same
agent that provides access to the local machine.  My concern is that the
generic API should not rely on input parameters that cannot readily be
acquired.  If the application has to make some system dependent calls to
collect credentials, then the code is no longer portable (w.r.t.
authentication).  I'd like to see the API contain an interface to the local
machine's credential store.     

>   Some sort of (possibly local) interface is needed for a Sign()ing process to
>   get at stored credentials, and expiration or non-existence error checks would
>   be appropriate in conjunction with this operation.  I'm not so sure about the
>   purity designation concept. I assume the need to trust correctly-applied local
>   mechanisms to preclude use of credential data by entities unrelated to the
>   corresponding Login(); such mediation appears intrinsic to an authentication
>   architecture which discriminates among principals located on the same computer.  
>   Is the goal of the purity designation mechanism to allow targets of access
>   attempts to make particular resources accessible only to peer processes which
>   directly possess passwords or analogous quantities, as a means to compensate in
>   part for possible inadequate assurance in the local mediation mechanism?  This
>   measure might have the negative result of forcing users to expose their
>   passwords at multiple points within a system so that the processes they
>   initiate can get "better" (more widely accepted) forms of credentials.   I
>   think we could avoid trouble by keeping the interface between human-entered and
>   computer-interoperable forms of authentication data as close to the
>   human-computer interface as possible; is this inconsistent with your implicit
>   trust and/or assurance model?
    
The "purity" designation was an attempt to capture a sense of liveness.  This
is equivalent to requiring the user to type their old password when changing
to a new password.  In general I am suspicious of applications that "think"
they need this kind of confirmation, but I don't know how to get around the
password setting case.

 Joe Pato
 Apollo Computer            A Subsidiary of Hewlett-Packard
 NSFNET: pato@apollo.com    UUCP: ...{attunix,uw-beaver,brunix}!apollo!pato

-------


1,,
Summary-line:  5-Jan  an Schimpf - DTN 226-5292  #Confirming meeting for Tuesday, January 9
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA07531; Fri, 5 Jan 90 08:47:20 EST
Received: from CRL.DEC.COM by ATHENA.MIT.EDU with SMTP
	id AA15158; Fri, 5 Jan 90 08:47:19 EST
Received: by crl.dec.com; id AA02430; Fri, 5 Jan 90 08:46:48 -0500
Received: by crltrx.crl.dec.com; id AA00291; Fri, 5 Jan 90 08:46:43 -0500
Received: by crltrx.crl.dec.com; id AA00282; Fri, 5 Jan 90 08:46:40 -0500
Received: by easynet.crl.dec.com; id AA04687; Fri, 5 Jan 90 08:37:11 -0500
Date: Fri, 5 Jan 90 08:37:06 -0500
Message-Id: <9001051337.AA04687@easynet.crl.dec.com>
From: schimpf@took.dec.com (Brian Schimpf - DTN 226-5292)
To: auth-api-ext@CRL.DEC.COM
Cc: SCHIMPF@CRL.DEC.COM
Subject: Confirming meeting for Tuesday, January 9

*** EOOH ***
Date: Fri, 5 Jan 90 08:37:06 -0500
From: schimpf@took.dec.com (Brian Schimpf - DTN 226-5292)
To: auth-api-ext@CRL.DEC.COM
Cc: SCHIMPF@CRL.DEC.COM
Subject: Confirming meeting for Tuesday, January 9

	This is a confirmation for the next meeting to discuss a common
authentication interface.  The meeting will be from 10:00 to 12:00 on
Tuesday, January 9 at Digital's Cambridge Research Lab.  The room is not
settled yet so ask at the reception area.

Thanks,

Brian Schimpf


1,forwarded,,
Summary-line: 11-Jan  3-5491.  11-Jan-1990 1439  #Athena and API definition activity
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA14358; Thu, 11 Jan 90 14:47:50 EST
Received: from DECWRL.DEC.COM by ATHENA.MIT.EDU with SMTP
	id AA10529; Thu, 11 Jan 90 14:47:29 EST
Received: by decwrl.dec.com; id AA11101; Thu, 11 Jan 90 11:46:52 -0800
Date: Thu, 11 Jan 90 11:46:37 -0800
Message-Id: <9001111946.AA11101@decwrl.dec.com>
From: linn@ULTRA.ENET.DEC.COM (John Linn. 508-264-5491. DTN 293-5491.  11-Jan-1990 1439)
To: jtkohl@ATHENA.MIT.EDU
Cc: LINN@ATHENA.MIT.EDU
Subject: Athena and API definition activity

*** EOOH ***
Date: Thu, 11 Jan 90 11:46:37 -0800
From: linn@ULTRA.ENET.DEC.COM (John Linn. 508-264-5491. DTN 293-5491.  11-Jan-1990 1439)
To: jtkohl@ATHENA.MIT.EDU
Cc: LINN@ATHENA.MIT.EDU
Subject: Athena and API definition activity

John,

At last Tuesday's CRL API meeting, we (DEC and HP/Apollo people) had a good
discussion, but missed the presence of an Athena representative.  We scheduled
the next meeting for Thursday, 25 January (again 10-12 at CRL), and will be
circulating updated proposals by E-mail in the interim.  Are you (or someone
else from Athena) still interested in pursuing this effort, and is the morning
of the 25th a suitable time to attend?  Please let me know your thoughts,
whether by return E-mail or phone.

Thanks,

John Linn

1,answered,,
Summary-line: 15-Jan  an Schimpf - DTN 226-5292  #Common authentication interface meeting - 1/9/90
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA04067; Mon, 15 Jan 90 18:46:28 EST
Received: from CRL.DEC.COM by ATHENA.MIT.EDU with SMTP
	id AA19026; Mon, 15 Jan 90 18:46:40 EST
Received: by crl.dec.com; id AA27063; Mon, 15 Jan 90 18:46:16 -0500
Received: by crltrx.crl.dec.com; id AA26395; Mon, 15 Jan 90 18:46:13 -0500
Received: by crltrx.crl.dec.com; id AA26388; Mon, 15 Jan 90 18:46:09 -0500
Received: by easynet.crl.dec.com; id AA14340; Mon, 15 Jan 90 18:43:51 -0500
Date: Mon, 15 Jan 90 18:43:49 -0500
Message-Id: <9001152343.AA14340@easynet.crl.dec.com>
From: schimpf@took.dec.com (Brian Schimpf - DTN 226-5292)
To: auth-api-ext@CRL.DEC.COM
Cc: NM@DECWRL::"att!attunix!billg", SCHIMPF@CRL.DEC.COM
Subject: Common authentication interface meeting - 1/9/90

*** EOOH ***
Date: Mon, 15 Jan 90 18:43:49 -0500
From: schimpf@took.dec.com (Brian Schimpf - DTN 226-5292)
To: auth-api-ext@CRL.DEC.COM
Cc: NM@DECWRL::"att!attunix!billg", SCHIMPF@CRL.DEC.COM
Subject: Common authentication interface meeting - 1/9/90


+---+---+---+---+---+---+---+
| d | i | g | i | t | a | l |     I N T E R O F F I C E   M E M O
+---+---+---+---+---+---+---+


                                   Date:  January 15, 1990
                                   From:  Brian C. Schimpf
                                   Dept:  Distributed Processing Engineering
                                   Ext:   226-5292
                                   Decnet:  TOOK::SCHIMPF
                                   Mail Stop:  LKG2-2/Z7

To:	  Distribution list

Subject:  Meeting to discuss common authentication interface

	A second meeting was held on the topic of a common authentication
programming interface.  The meeting was held on Tuesday, January 9, 1990 and
was a follow up to a meeting held December 21, 1989.  Attendees at the meeting 
were:

	Bill Brown		Digital (ULTRIX)
	Charlie Kaufman		Digital (Networks and Communications)
	Butler Lampson		Digital (CRL)
	John Linn		Digital (Secure Systems)
	Joe Pato		HP/Apollo
	Richard Pitkin		Digital (Distributed Processing)
	Brian Schimpf		Digital (Distributed Processing)
	Bill Sommerfeld		HP/Apollo
	John Williams		Digital (ULTRIX)

	The first discussion had to do with participation in these meetings.
Brian Schimpf had been approached by Bill Griffeth of AT&T expressing interest
in what this group is doing.  John Williams had been approached by someone at
MITRE.  Richard Pitkin will shortly be attending another multivendor meeting
dealing with computer security and would like to report on these meetings at
that discussion.  The participants all agreed that unless the logistics become
a problem these meetings will continue to be open and that the results of the
meetings may be shared freely.  If one of the participants shares information
with someone outside of his/her company or organization s/he should let the
other participants know as a courtesy.  It was also mentioned that we should
expect participants to be in a position to make technical contributions and 
not just act as observers.

	Since the last meeting two proposals had been circulated via email,
one from Digital and one from HP/Apollo.  Butler Lampson questioned why the
two proposals looked different and could we drive toward a more common view?
The feeling seemed to be that the Digital proposal had tried to be as simple
as possible with the understanding that it might have to get more complicated
in case it didn't do everything that needed to be done.  The HP proposal was
an attempt to be complete without too much regard to how easy it would be for
applications programmers to use it.

	We began a list of issues to be dealt with:

  * How are credentials made available to applications?
  * Can the interface completely hide message exchanges as part of
    associations?
  * How important is this hiding?
  * Could the interface require that clients know (determine) some attribute
    of the server?

The first issue was felt to be important but not as hard as the others (which
are related) so they became the focus of the rest of the discussion.  The 
problem was expressed as a tradeoff:

  * The interface should be useable by a wide variety of applications.
  * The interface should support a variety of authentication mechanisms.

These two influences pull in opposite directions.  Both can probably be
satisfied with a sufficiently complicated interface, but there was concern
about how complicated the interface can be before applications developers
won't want to use it.

	The following list of conclusions was written down:

  * The interface can neither require nor preclude writing kernel software.
  * The interface can neither require nor preclude writing multithreaded code.
  * It must be possible to hide keys from the application.
  * It will be possible to layer less generic (and thus easier-to-use)
    functions on top of a very generic interface.  [We might want to define
    one or two of these as useful examples.]
  * There should be no "hidden" communications between principals.
  * The interface <will | may> require multiple invocations via a "retry-
    style" mechanism.

	It was agreed that before the next meeting HP and Digital would look
over the proposals and see if we can't move toward a more common view.  Also,
everyone should look at the issue list to see if we can get a more complete
list of issues that need to be addressed.  One issue for that list is naming,
with the proposal being that this interface ought to use an opaque string as
the name.  A good time for the next meeting seemed to be the morning of
Thursday, January 25, 1990.  I will check on the arrangements for that and
in particular to see if that time is good for any of the folks from Athena,
since none of them were able to make this meeting.  I will send out a 
confirmation soon.


Distribution:  Attendees of December 21 meeting
	       Bill Griffeth  	AT&T

                            [End of Minutes]


1,,
Summary-line: 16-Jan  John T Kohl                #Re: Common authentication interface meeting - 1/9/90
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA07672; Tue, 16 Jan 90 10:43:17 EST
Received: from LYCUS.MIT.EDU by ATHENA.MIT.EDU with SMTP
	id AA00568; Tue, 16 Jan 90 10:43:31 EST
Received: by lycus.MIT.EDU (5.61/4.7) id AA15632; Tue, 16 Jan 90 10:43:08 -0500
Date: Tue, 16 Jan 90 10:43:08 -0500
From: John T Kohl <jtkohl@ATHENA.MIT.EDU>
Message-Id: <9001161543.AA15632@lycus.MIT.EDU>
To: schimpf@TOOK.ENET.DEC.COM
Cc: jis@ATHENA.MIT.EDU, jon@ATHENA.MIT.EDU
In-Reply-To: Brian Schimpf - DTN 226-5292's message of Mon, 15 Jan 90 18:43:49 -0500,
	<9001152343.AA14340@easynet.crl.dec.com>
Subject: Re: Common authentication interface meeting - 1/9/90
X-Us-Snail: MIT Room E40-351, 1 Amherst St., Cambridge, MA 02139 USA

*** EOOH ***
Date: Tue, 16 Jan 90 10:43:08 -0500
From: John T Kohl <jtkohl@ATHENA.MIT.EDU>
To: schimpf@TOOK.ENET.DEC.COM
Cc: jis@ATHENA.MIT.EDU, jon@ATHENA.MIT.EDU
In-Reply-To: Brian Schimpf - DTN 226-5292's message of Mon, 15 Jan 90 18:43:49 -0500,
	<9001152343.AA14340@easynet.crl.dec.com>
Subject: Re: Common authentication interface meeting - 1/9/90

Thursday 25 January is in the middle of the Usenix conference in DC...I
certainly can't make the meeting; I don't know the plans of the other
Athena people, though.

John

1,,
Summary-line: 21-Jan  an Schimpf - DTN 226-5292  #Next meeting
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA08952; Sun, 21 Jan 90 18:48:49 EST
Received: from crl.dec.com by ATHENA.MIT.EDU with SMTP
	id AA15660; Sun, 21 Jan 90 18:49:09 EST
Received: by crl.dec.com; id AA03538; Sun, 21 Jan 90 18:48:28 -0500
Received: by crltrx.crl.dec.com; id AA01550; Sun, 21 Jan 90 18:48:24 -0500
Received: by crltrx.crl.dec.com; id AA01540; Sun, 21 Jan 90 18:48:21 -0500
Received: by easynet.crl.dec.com; id AA25597; Sun, 21 Jan 90 18:44:05 -0500
Date: Sun, 21 Jan 90 18:44:04 -0500
Message-Id: <9001212344.AA25597@easynet.crl.dec.com>
From: schimpf@took.dec.com (Brian Schimpf - DTN 226-5292)
To: auth-api-ext@CRL.DEC.COM
Cc: SCHIMPF@CRL.DEC.COM
Subject: Next meeting

*** EOOH ***
Date: Sun, 21 Jan 90 18:44:04 -0500
From: schimpf@took.dec.com (Brian Schimpf - DTN 226-5292)
To: auth-api-ext@CRL.DEC.COM
Cc: SCHIMPF@CRL.DEC.COM
Subject: Next meeting

	We had tentatively set up the next meeting for this coming 
Thursday, January 25.  John Kohl from Athena indicated that this would
be bad for him because of the Usenix conference.  I will be out of the
office for this entire week so I am leaving this issue in the hands of
Richard Pitkin, on system TOOK at Digital.  If you have a preference
for the meeting either being held as scheduled or rescheduled please
let Richard know ASAP.  Richard, please coordinate with Win Treese at
CRL about whether a room will be needed or not.

Thanks,

Brian Schimpf


1,,
Summary-line: 16-Jan  3-5491.  16-Jan-1990 1249  #Revised strawperson authentication API proposal
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA08656; Tue, 16 Jan 90 12:58:25 EST
Received: from crl.dec.com by ATHENA.MIT.EDU with SMTP
	id AA03824; Tue, 16 Jan 90 12:58:31 EST
Received: by crl.dec.com; id AA29397; Tue, 16 Jan 90 12:57:50 -0500
Received: by crltrx.crl.dec.com; id AA10121; Tue, 16 Jan 90 12:57:47 -0500
Received: by crltrx.crl.dec.com; id AA10113; Tue, 16 Jan 90 12:57:43 -0500
Received: by easynet.crl.dec.com; id AA16001; Tue, 16 Jan 90 12:54:14 -0500
Date: Tue, 16 Jan 90 12:54:11 -0500
Message-Id: <9001161754.AA16001@easynet.crl.dec.com>
From: linn@bombe.dec.com (John Linn. 508-264-5491. DTN 293-5491.  16-Jan-1990 1249)
To: auth-api-ext@CRL.DEC.COM
Cc: LINN@CRL.DEC.COM
Subject: Revised strawperson authentication API proposal

*** EOOH ***
Date: Tue, 16 Jan 90 12:54:11 -0500
From: linn@bombe.dec.com (John Linn. 508-264-5491. DTN 293-5491.  16-Jan-1990 1249)
To: auth-api-ext@CRL.DEC.COM
Cc: LINN@CRL.DEC.COM
Subject: Revised strawperson authentication API proposal

This message updates the provisional API proposal presented earlier this month
to reflect discussion at the 9 January CRL meeting.  It includes support for
multiple message transactions such as the Kerberos double-TGT protocol.

--John Linn

-------------------------

The following is a proposal for organization of a generic interface to a data
origin authentication service, which can accomodate either Kerberos or
public-key cryptography as underlying technologies with minimal impact on
calling applications.  This interface will not exploit the full capabilities of
either system, but will meet the authentication needs of the majority of
applications.   Applications written to this interface will be "portable".  
The interface is independent of the communications protocol suite(s) with which
it is used, or of connection vs. connectionless orientation of that
communications service.  While it is the application's responsibility to
transfer authentication-related information to its peer, and to distinguish
that information from other data carried across that communications path, the
interface relieves applications of the burdens attendant to managing control
communications with authentication servers.

This service provides mechanisms to sign messages, to verify signatures, and to
request delegation of access rights from an initiator to a target of
authentication information. Through use of the service, initiating principals
securely demonstrate their identities to targets in a distributed computing
environment.  An initiator invokes a Sign() operation, yielding results which a
target processes with a Verify() operation. The service is independent of
underlying protocols and addressing structure, although callers will in some
cases provide protocol-specific information as input to the interface. The
authentication service inserts timestamps into output authentication messages
and maintains (within a time-limited window) a cache of input authentication
messages in order to provide a level of replay detection. (An implicit tradeoff
exists between timestamp resolution and possible resulting cache size.) Support
for the replay detection cache is a local implementation issue at a target
system, and may be omitted if this security feature is not required at a
particular system.

The service's operations depend on data structures called credentials, which
are created, used, and modified as a result of invoking the API's calls.  The
contents of credentials structures will vary depending on the underlying
authentication type in use, but their internal semantics are opaque from the
viewpoint of callers.  Since credentials structures contain sensitive data,
local measures are expected to be used to secure those structures against
unauthorized access.  As the implementation of such protection measures is a
local matter, the form of "handles" provided to callers in order to reference
credentials may vary among different systems.

As far as the interface is concerned, authenticated names are opaque strings
with no structure dictated.  It must be recognized, however, that underlying
authentication mechanisms will impose constraints on naming representations. 
Translation between different naming representations is a function outside the
scope of this interface.

The caller is assumed to determine the appropriate authentication type
(auth_type) for authentication to a target peer through means outside this
interface.  In some cases, such determinations may be made by examining a
target name; in other cases, a database or naming service attribute lookup may
be needed in order to provide auth_type information corresponding to a provided
name.  We need a registry of auth_type identifiers.  To avoid frequent
invocations of error paths when supporting Kerberos V5, I suggest that
"single-TGT K-V5" and "double-TGT K-V5" be separate auth_types.  Observe that
the set of auth_types which an entity may assert in authenticating itself to
others need not be the same as the set of auth_types with which it can accept
incoming authentications from others. A single credentials structure is assumed
per caller, even if that caller uses multiple auth_types in order to
authenticate to different peers; an alternative approach would represent each
auth_type employed by a caller with a separate credentials structure.

---------------------------

Proposed interfaces:

	Login(myname,mypassword,expiration,auth_types) returns (credentials)

	arguments: 
	    myname is the name of the entity logging in
	    mypassword is its password
	    expiration is the desired expiration interval for the ticket
	    auth_types is a list of underlying authentication types for
	      which corresponding tickets and session keys should be 
	      returned in credentials

	results:
	    credentials contains the name of the authenticated entity,
	      includes a ticket structure (or structures, if multiple
	      auth_types are requested) which can be presented to
	      assert the entity's identity, and provides
	      a cryptographic session key (keys, if multiple auth_types),
              use of which serves to demonstrate the entity's authorized 
              ownership of the ticket

The Login() interface provides a standardized means for an entity to
demonstrate its identity through presentation of a password and to receive
appropriate authentication credentials.  Its definition and inclusion is not
intended to preclude use of other authentication techniques (e.g., smart
cards) and associated interfaces providing interchangeable credentials. The
returned ticket will be presented either to an authentication server  or
directly to an application's peer, depending on underlying authentication
type; significantly, in either case, the returned ticket is independent
of the particular peers to which the authenticated entity will need to
demonstrate its identity.

	Sign(message,credentials,target,deleg_flag,auth_type,per_msg_info)
		returns (status,assoc_info,per_msg_info)

	arguments:
	    message is an application-specific block of bits to be signed
	    credentials is the data returned by Login (or Verify)
	    target is the name of the intended recipient of the	message
	    deleg_flag is set if delegation to the target should be
	      piggy-backed on the signing operation
	    auth_type indicates the underlying authentication type 
	      appropriate for the target
	    per_msg_info, input only in conjunction with an outstanding
	      RETRY_NEEDED transaction (see below) carries control 
	      information received from a target system which is needed
	      in order to complete the Sign() function

	results:
	    status allows the caller to distinguish different cases
	      and interpret the subsequent arguments correctly:
		- COMPLETE indicates that the input message was
		  successfully signed and can be sent to the target
		  along with per_msg_info; there are two subcases:
		  - SEND_ASSOC_INFO indicates that the assoc_info
		    is new, or changed from its previous value,
		    so must be sent to the target with the message
		    to replace any cached assoc_info
		  - SAME_ASSOC_INFO indicates that the assoc_info
		    is unchanged from its previously existing value,
		    so target-cached assoc_info can be reused
		- RETRY_NEEDED indicates that control information in
		  the returned per_msg_info must be sent to the peer 
		  before signing can be completed. No assoc_info
		  is returned at this point. The caller 
		  should expect to receive response per_msg_info in a 
		  message from the peer and to pass that per_msg_info
		  as input to a subsequent Sign(). 
		- FAILURE indicates that the signing operation could
		  not be accomplished and that no interface-defined
		  recovery action is available. 
                  Example type codes include:
		  - authentication server not available
		  - auth_type not supported at remote system
		  - peer's control information was defective
	    assoc_info provides association-level information to be
	      sent to the peer system's authentication function, 
	      naming the signer and incorporating a
	      suitable ticket to authenticate the signer to the target
	    per_msg_info contains per-message data to be sent to 
              the authentication function at the peer system.  
              For signature of user messages,
              per_msg_info will contain transformation of the 
              input message and a timestamp, performed with the session key 
              corresponding to the ticket carried in assoc_info.  When 
	      status indicates RETRY_NEEDED in the course of establishing
	      an association, per_msg_info will contain control information
	      for the peer's authentication function.

Specification of an auth_type which was not included in the signer's initial
Login() may result in an error, unless credential conversion functions are
available.  The returned assoc_info must be accessible to the target
in order to successfully verify any message signed with the current
credentials, but can often be cached by the target so as to avoid the need
for retransmission of this data during an ongoing association.  The (normally
smaller) per_msg_info is message-specific, so must be transferred with
each signed message.

	Verify(message,assoc_info,per_msg_info,target_credentials)
	    returns (status,signing_time,originator_data,credentials,auth_type,
	      per_msg_info)

	arguments:
	      message is the block of bits supposedly signed
	      assoc_info is as returned by Sign() at the source system
		and sent to the target, possibly recovered from 
                a target-maintained cache
	      per_msg_info is as returned by Sign() at the source system
		and sent to the target
	      target_credentials is a credentials structure containing
		keys associated with the target

	results:
	      status assumes the following values:
		- GOOD: message from peer, successfully verified with valid
		  signature and non-duplicate timestamp within window
		- BAD: message from peer, signature invalid
		- DUPLICATE: message from peer, valid signature
		  but with timestamp duplicating an existing entry 
		  in the replay detection cache
		- GOOD BUT EXPIRED: message from peer, valid signature
		  but with a timestamp sufficiently
		  obsolete as to be outside the replay detection cache's
		  time window
		- SEND_CTRL indicates that the returned per_msg_info
		  result contains control information for the peer's 
		  authentication function and that the caller must send 
		  it to the peer; no user message is received or verified 
		  in conjunction with this return status, and returned 
		  arguments other than per_msg_info are not meaningful
	      signing_time corresponds to the timestamp inserted by Sign()
	      originator_data identifies the principal who signed the
		message (TBD whether the principal's name is returned
                directly or whether a structure is returned from which the
		name can be extracted by other routines)
	      credentials is returned only as a result of a valid verified
		message which delegated to the target, processed
	 	by a Verify() call with valid input target_credentials;
                the returned credentials can be used by the target 
                in further calls to Sign.
	      auth_type indicates the underlying authentication type
		used in the Verify() operation
	      per_msg_info, present only when indicated by returned
		SEND_CTRL status, contains control information to be sent
		to the peer for processing by the authentication function
		at the peer's system.

Notes:

This interface assumes that the conjunction of a set of user credentials
established by a Login() operation and a named authentication target is
sufficient to qualify an authentication association; the interface does not
distinguish multiple associations involving the same source credentials and
target name.

It is a caller's prerogative to determine the disposition of duplicate and
expired messages (as indicated by Verify() return codes) which are sent to it
by a peer application.  


1,,
Summary-line: 29-Jan  226-7121)                  #Minutes from Athena meeting,January 25, 1990
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA22342; Mon, 29 Jan 90 11:06:29 EST
Received: from CRL.DEC.COM by ATHENA.MIT.EDU with SMTP
	id AA17267; Mon, 29 Jan 90 11:07:17 EST
Received: by crl.dec.com; id AA25286; Mon, 29 Jan 90 11:06:12 -0500
Received: by crltrx.crl.dec.com; id AA01654; Mon, 29 Jan 90 11:06:08 -0500
Received: by crltrx.crl.dec.com; id AA01646; Mon, 29 Jan 90 11:06:04 -0500
Received: by easynet.crl.dec.com; id AA15360; Mon, 29 Jan 90 11:04:26 -0500
Date: Mon, 29 Jan 90 11:04:23 -0500
Message-Id: <9001291604.AA15360@easynet.crl.dec.com>
From: pitkin@took.dec.com (Richard {e**PI*i = -1} (226-7121))
To: auth-api-ext@CRL.DEC.COM
Cc: PITKIN@CRL.DEC.COM
Subject: Minutes from Athena meeting,January 25, 1990

*** EOOH ***
Date: Mon, 29 Jan 90 11:04:23 -0500
From: pitkin@took.dec.com (Richard {e**PI*i = -1} (226-7121))
To: auth-api-ext@CRL.DEC.COM
Cc: PITKIN@CRL.DEC.COM
Subject: Minutes from Athena meeting,January 25, 1990


  D R A F T  -  For review

+---+---+---+---+---+---+---+
| d | i | g | i | t | a | l |     I N T E R O F F I C E   M E M O
+---+---+---+---+---+---+---+


                                   Date:  January 26, 1990
                                   From:  Richard Pitkin
                                   Dept:  Distributed Processing Engineering
                                   Ext:   DTN 226-7121
                                   DECnet:  TOOK::PITKIN
                                   Mail Stop:  LKG2-2/Z7

To:	  Distribution

Subject:  Meeting on discussing common authentication interface

	A meeting was held on Thursday, January 25,1990 at Digital's 
Cambridge Research Lab.  The goal of the meeting was to continue dialog
regarding the definition of a common application programming interface for
distributed authentication.  Attendees at the meeting were:

	Bill Brown		Digital (ULTRIX)
	Charlie Kaufman		Digital (Networks and Communications)
	John Linn		Digital (Secure Systems)
	Richard Pitkin		Digital (Distributed Processing)
	Jon Rochlis		MIT/Project Athena
        Kannan Alagappan        Digital (Networks and Communications)


The meeting went well.  The majority of the meeting was taken with
Jon Rochlis filling in the Digital attendees on the status of 
Kerberos at Project Athena.  We had hoped for Jeff Schiller to attend
but he was unable to participate.  No technical discussion took place.

Jon related the following facts about Project Athena:

 o  Jon provided the Kerberos view that "adding authentication
    to network applications should be 'painless'".

 o  Berkley V4.4 was not a goal for Kerberos V5

 o  Staff at Athena has more work than time to finish it all.

 o  Since Kerberos V4 does work, Kerberos V5 is not a high priority.

 o  John Kohl and Jeff Schiller are the most directly responsible for
    getting Kerberos V5 done.  Both are self motivated to respond 
    concerning outside users requests for functionality.

 o  Project Athena will provide at least on application library that
    is upward compatible from V4 to V5 Kerberos.  The ability to 
    provide a second library that used the generic interface is
    desirable, but would not hold back V5 development.

 o  Jon provided an update about MIT's support for Internet standards
    efforts.

 o  Project Athena staff do not have time to participate in designing
    a generic interface.

Conclusions:

 Digital (and HP/Apollo) should draft a proposed generic interface.
This proposal would include examples of how V4, V5, and possibly X.509
services would use the interface.  
Jon felt that with a two to three week reading period after the proposal
was distributed, that a review could take place at MIT. (We need Jeff
Schiller to formally agree to this.)  Project Athena-Kerberos would then
decide on the basis of the review on the inclusion of the proposed interface
into a Kerberos library.  

Details remaining:
  1) How HP/Apollo and Digital would coordinate the design.
  2) Jeff Schiller's and John Kohl's agreement.
  3) Time needed to read and discuss the proposal before the review.
  4) Method for resolution of minor technical details.


                            [End of Minutes]


1,,
Summary-line: 29-Jan  John T Kohl                #API stuff
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA22465; Mon, 29 Jan 90 11:18:25 EST
Received: from LYCUS.MIT.EDU by ATHENA.MIT.EDU with SMTP
	id AA17645; Mon, 29 Jan 90 11:19:15 EST
Received: by lycus.MIT.EDU (5.61/4.7) id AA16217; Mon, 29 Jan 90 11:18:16 -0500
Date: Mon, 29 Jan 90 11:18:16 -0500
From: John T Kohl <jtkohl@ATHENA.MIT.EDU>
Message-Id: <9001291618.AA16217@lycus.MIT.EDU>
To: jon@ATHENA.MIT.EDU, jis@ATHENA.MIT.EDU
Subject: API stuff
X-Us-Snail: MIT Room E40-351, 1 Amherst St., Cambridge, MA 02139 USA

*** EOOH ***
Date: Mon, 29 Jan 90 11:18:16 -0500
From: John T Kohl <jtkohl@ATHENA.MIT.EDU>
To: jon@ATHENA.MIT.EDU, jis@ATHENA.MIT.EDU
Subject: API stuff

We should talk (probably briefly) about the API stuff when you return
from LA.

John

1,,
Summary-line: 29-Jan  Evaluation: (617)621-8849  #Re: Minutes from Athena meeting,January 25, 1990 
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA22510; Mon, 29 Jan 90 11:21:25 EST
Received: from CRL.DEC.COM by ATHENA.MIT.EDU with SMTP
	id AA17708; Mon, 29 Jan 90 11:22:12 EST
Received: by crl.dec.com; id AA25395; Mon, 29 Jan 90 11:21:04 -0500
Received: by crltrx.crl.dec.com; id AA02157; Mon, 29 Jan 90 11:20:57 -0500
Received: by crltrx.crl.dec.com; id AA02149; Mon, 29 Jan 90 11:20:51 -0500
Received: by crl.dec.com; id AA25370; Mon, 29 Jan 90 11:18:37 -0500
Received: from cactus.osf.org by osf.osf.org (5.61/OSF 0.9)
	id AA15286; Mon, 29 Jan 90 11:18:13 -0500
Message-Id: <9001291618.AA15286@osf.osf.org>
To: pitkin@took.enet.dec.com (Richard {e**PI*i = -1} (226-7121))
Cc: auth-api-ext@CRL.DEC.COM, PITKIN@CRL.DEC.COM
Subject: Re: Minutes from Athena meeting,January 25, 1990 
In-Reply-To: Your message of Mon, 29 Jan 90 11:04:23 -0500.
             <9001291604.AA15360@easynet.crl.dec.com> 
Date: Mon, 29 Jan 90 11:18:11 -0500
From: "Brad C. Johnson: OSF DAE Evaluation: (617)621-8849" <bradcj@OSF.ORG>

*** EOOH ***
To: pitkin@took.enet.dec.com (Richard {e**PI*i = -1} (226-7121))
Cc: auth-api-ext@CRL.DEC.COM, PITKIN@CRL.DEC.COM
Subject: Re: Minutes from Athena meeting,January 25, 1990 
In-Reply-To: Your message of Mon, 29 Jan 90 11:04:23 -0500.
             <9001291604.AA15360@easynet.crl.dec.com> 
Date: Mon, 29 Jan 90 11:18:11 -0500
From: "Brad C. Johnson: OSF DAE Evaluation: (617)621-8849" <bradcj@OSF.ORG>

Richard and company,

>Digital (and HP/Apollo) should draft a proposed generic interface.

Where does the evaluation of the AT&T authentication API fit into this work?

I'm assuming it makes sense to evaluate the AT&T work as it *will* be
in their 4.1 security release and it doesn't make sense to say "we came
up with something different because we didn't take the time to review
an existing proposal."

Brad


1,answered,filed,,
Summary-line:  1-Mar  bbrown@DECVAX.DEC.COM      #Generic Authentication Interface
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA23409; Thu, 1 Mar 90 17:19:11 EST
Received: from decvax.dec.com by ATHENA.MIT.EDU with SMTP
	id AA15424; Thu, 1 Mar 90 16:17:37 EST
Received: by decvax.dec.com (5.57/v2.4)
	id AA05146; Thu, 1 Mar 90 16:12:56 -0500
Received: by abyss.zk3.dec.com (5.57/dv.5.yp)
	id AA12109; Thu, 1 Mar 90 16:15:04 -0500
Message-Id: <9003012115.AA12109@abyss.zk3.dec.com>
To: jtkohl@ATHENA.MIT.EDU
Cc: bbrown@DECVAX.DEC.COM
Subject: Generic Authentication Interface
Date: Thu, 01 Mar 90 16:15:00 EST
From: bbrown@DECVAX.DEC.COM

*** EOOH ***
To: jtkohl@ATHENA.MIT.EDU
Cc: bbrown@DECVAX.DEC.COM
Subject: Generic Authentication Interface
Date: Thu, 01 Mar 90 16:15:00 EST
From: bbrown@DECVAX.DEC.COM

Hi,
	This is the current proposal for a Generic Authentication
Interface.  It is either the last or the second to last before it is
shown outside of DEC.  Please comment.  If possible, please place
emphasis on Kerberos v5 compatability.
	I believe that it has come a long way towards an interface
which is, from a Kerberos API point of view, useable.  At the same time
it eliminates all of the arbitrary and Kerberos specific features of
the Kerberos API.

							Bill
p.s. How is the v5 implementation work proceeding?

------- Forwarded Message

Return-Path: linn@ultra.enet
Date: Wed, 28 Feb 90 16:07:02 -0500
From: linn@ultra.enet (John Linn. 508-264-5491. DTN 293-5491.  28-Feb-1990 1533)
To: @satf, bbrown@abyss.enet, kannan@sejour.enet, palka@prfect.enet,
        tardo@tardo.enet, pitkin@took.enet, hoeger@satan.enet, hlh@abyss.enet,
        barlow@decwet.enet
Cc: LINN
Subject: Generic Security Service API (PostScript), last call before Athena

%!PS-Adobe-2.0
%%Creator: VAX DOCUMENT V1.2B
%%+Copyright (c) 1986,1987,1988,1989 DIGITAL EQUIPMENT CORPORATION.  
%%+All Rights Reserved.
%%DocumentFonts: (atend)
%%Pages: (atend)
%%EndComments
/DEC_DVC$dict where {					%FIND DICTIONARY
  pop
}{ %else
  /DEC_DVC$dict 300 dict def
} ifelse 
/BeginDVC$PSDoc {					%BEGIN DOCUMENT
  vmstatus pop pop 0 eq {
    DEC_DVC$dict begin  InitializeState
  }{ %else
    /DVC$PSJob save def  DEC_DVC$dict begin  InitializeState
    /DVC$PSFonts save def
  } ifelse
} def
/EndDVC$PSDoc {						%END DOCUMENT
% --- Preserving current page count ---
  vmstatus pop pop 0 eq {
    end
  }{ %else
    DVC$PSFonts restore  end  DVC$PSJob restore
  } ifelse
} def
%
DEC_DVC$dict begin
%
mark					% CREATE ISOLatin1 ENCODING
/ISOLatin1
  8#000 1 8#054 {StandardEncoding exch get} for 
  /minus
  8#056 1 8#217 {StandardEncoding exch get} for 
  /dotlessi 
  8#301 1 8#317 {StandardEncoding exch get} for 
  /space /exclamdown /cent /sterling /currency /yen /brokenbar /section 
  /dieresis /copyright /ordfeminine /guillemotleft /logicalnot /hyphen 
  /registered /macron /degree /plusminus /twosuperior /threesuperior /acute 
  /mu /paragraph /periodcentered /cedilla /onesuperior /ordmasculine 
  /guillemotright /onequarter /onehalf /threequarters /questiondown /Agrave 
  /Aacute /Acircumflex /Atilde /Adieresis /Aring /AE /Ccedilla /Egrave /Eacute 
  /Ecircumflex /Edieresis /Igrave /Iacute /Icircumflex /Idieresis /Eth /Ntilde 
  /Ograve /Oacute /Ocircumflex /Otilde /Odieresis /multiply /Oslash /Ugrave 
  /Uacute /Ucircumflex /Udieresis /Yacute /Thorn /germandbls /agrave /aacute 
  /acircumflex /atilde /adieresis /aring /ae /ccedilla /egrave /eacute 
  /ecircumflex /edieresis /igrave /iacute /icircumflex /idieresis /eth /ntilde
  /ograve /oacute /ocircumflex /otilde /odieresis /divide /oslash /ugrave 
  /uacute /ucircumflex /udieresis /yacute /thorn /ydieresis 
  /ISOLatin1 where not {256 array astore def} if 
cleartomark
%
/DECMCS ISOLatin1 256 array copy def
mark						% CREATE DECMCS ENCODING
  8#240 8#244 8#246 8#254 8#255 8#256 8#257 8#264 
  8#270 8#276 8#320 8#336 8#360 8#376 8#377
  counttomark
  {DECMCS exch /.notdef put} repeat		% STACK NOW CONTAINS MARK
  8#250 /currency   8#327 /OE   8#335 /Ydieresis   8#367 /oe   8#375 /ydieresis
  counttomark -1 bitshift			% DIVIDE BY 2
  {DECMCS 3 1 roll put} repeat			% STACK NOW CONTAINS MARK
cleartomark
%
/DOCPSE DECMCS 256 array copy def 
mark						% CREATE DOCPSE ENCODING
  8#055 /hyphen
  8#201 /bullet    8#202 /emdash     8#203 /endash    8#204 /dagger
  8#205 /daggerdbl 8#206 /registered 8#207 /trademark %8#210 /Delta
  8#211 /fi        8#212 /fl
  counttomark -1 bitshift			% DIVIDE BY 2
  {DOCPSE 3 1 roll put} repeat			% STACK NOW CONTAINS MARK
cleartomark
%
/reencodedict 10 dict def			%Local storage for "ReENCODE"
/ReENCODE {		% /basefont /newfont encoding ReENCODE
    /newencoding exch def	%ARG: NAME OF ENCODING VECTOR
    /newfontname exch def	%ARG: NEW NAME FOR FONT AFTER RE-ENCODING
    findfont
    /basefontdict exch def	%ARG: NAME OF FONT TO BE RE-ENCODED
    basefontdict maxlength dict begin	%CREATE AND OPEN NEW DICT
	basefontdict {		%COPY ENTRIES FROM BASE FONT DICT TO NEW ONE
	    1 index /FID ne {
		def		%IF NOT THE ONE WE'RE ENCODING, JUST COPY PTRS
	    } { %else
		pop pop		%IGNORE FID AND ENCODING FOR ONE WE'RE ENCODING
	    } ifelse
	} forall
	/FontName newfontname def	%DEFINE NEW NAME 
	/Encoding newencoding def	%DEFINE NEW ENCODING VECTOR
	newfontname currentdict definefont	%TURN IT INTO A PS FONT
	pop			%IGNORE MODIFIED DICT RETURNED BY DEFINEFONT
    end
} bind def
%
/cvsstr 64 string def
/tempmatrix matrix def
%
/BP {							% BEGIN PAGE
  /Magnification exch def
  /Colorsused 0 def
  /RVmatrix matrix def
  /DVC$PSPage save def
} def
%
/EP {DVC$PSPage restore} def				% END PAGE
%
/XP {				% EXIT PAGE (TEMPORARILY) TO ADD FONTS/CHARS
  % SAVE CURRENT POINT AND COLOR INFORMATION SO IT CAN BE RESET LATER
  matrix currentmatrix aload pop currentrgbcolor Colorsused
  /Xpos where {pop Xpos} {0} ifelse
  /Ypos where {pop Ypos} {0} ifelse
  /currentpoint cvx stopped {0 0 moveto currentpoint} if 
  /DVC$PSPage where {pop DVC$PSPage restore} if
  moveto
  /Ypos exch def  /Xpos exch def
  /Colorsused exch def setrgbcolor
  matrix astore setmatrix
} def
%
/RP {/DVC$PSPage save def} def		% RESUME PAGE
%
/PF {GlobalMode  LocalMode} def			% PURGE FONTS TO RECLAIM MEMORY
%
/GlobalMode {		% SWITCH TO BASE SAVE/RESTORE LEVEL, SAVING STATE
  RVmatrix aload pop
  PortraitMode  PaperWidth  PaperHeight  PxlResolution  Resolution 
  Magnification Ymax        Xorigin      Yorigin        RasterScaleFactor
  % SAVE CURRENTPOINT INFORMATION TO RESET LATER
  /currentpoint cvx stopped {0 0 moveto currentpoint} if 
  /DVC$PSPage where {pop DVC$PSPage restore} if
  DVC$PSFonts restore  RecoverState
} def
%
/RecoverState {					% PRESERVE STATE AT BASE LEVEL
  18 copy
  /Ypos exch def           /Xpos exch def        /RasterScaleFactor exch def
  /Yorigin exch def        /Xorigin exch def     /Ymax exch def
  /Magnification exch def  /Resolution exch def  /PxlResolution exch def
  /PaperHeight exch def    /PaperWidth exch def  /PortraitMode exch def
  matrix astore /RVmatrix exch def
  DoInitialScaling
  RVmatrix concat
  PortraitMode not {PaperWidth 0 SetupLandscape} if
  Xpos Ypos moveto
} def
%
/InitializeState {		% INITIALIZE STATE VARIABLES TO DEFAULT VALUES
  /Resolution 3600 def  /PxlResolution 300 def
  /RasterScaleFactor PxlResolution Resolution div def
  /PortraitMode true def
  /Magnification 1000 def  /Xorigin 0 def  /Yorigin 0 def
  /Xpos 0 def  /Ypos 0 def  /InitialMatrix matrix currentmatrix def
  /Colorsused 0 def /RVmatrix matrix def
} def
%
/LocalMode {		% SWITCH FROM BASE SAVE/RESTORE LEVEL, RESTORING STATE
  /Ypos exch def  /Xpos exch def  /RasterScaleFactor exch def
  /Yorigin exch def  /Xorigin exch def  /Ymax exch def
  /Magnification exch def  /Resolution exch def  /PxlResolution exch def
  /PaperHeight exch def  /PaperWidth exch def  /PortraitMode exch def
  matrix astore /RVmatrix exch def
  DoInitialScaling
  RVmatrix concat
  PortraitMode not {PaperWidth 0 SetupLandscape} if
  Xpos Ypos moveto
  /DVC$PSFonts save def  /DVC$PSPage save def
} def
%							% ABBREVIATIONS 
/S /show load def
/SV /save load def
/RST /restore load def
/Yadjust {Ymax exch sub} def
%
/SXY {		% (x,y) POSITION ABSOLUTE, JUST SET Xpos & Ypos, DON'T MOVE
  Yadjust  /Ypos exch def /Xpos exch def
} def
%
/XY {						% (x,y) POSITION ABSOLUTE
  Yadjust  2 copy /Ypos exch def /Xpos exch def  moveto
} def
%
/X {						% (x,0) POSITION ABSOLUTE
  currentpoint exch pop   2 copy /Ypos exch def /Xpos exch def  moveto
} def
%
/Y {						% (0,y) POSITION ABSOLUTE 
  currentpoint pop exch Yadjust  2 copy
  /Ypos exch def /Xpos exch def  moveto
} def
%
/xy {						% (x,y) POSITION RELATIVE
  neg rmoveto  currentpoint /Ypos exch def /Xpos exch def
} def
%
/x {						% (x,0) POSITION RELATIVE
  0 rmoveto  currentpoint /Ypos exch def /Xpos exch def
} def
%
/y {						% (0,y) POSITION RELATIVE
  0 exch neg rmoveto  currentpoint /Ypos exch def /Xpos exch def
} def
%
/R {						% DRAW A RULE
  /ht exch def  /wd exch def   gsave
% 0 setgray
  currentpoint  newpath  moveto
  0 ht rlineto  wd 0 rlineto
  0 ht neg rlineto  wd neg 0 rlineto
  closepath fill  grestore  wd 0 rmoveto
  currentpoint /Ypos exch def /Xpos exch def
} def
%
/RES {		% <PXL-file resolution(pix/inch)> <resolution(pix/inch)> RES
  /Resolution exch def  /PxlResolution exch def
  /RasterScaleFactor PxlResolution Resolution div def
  DoInitialScaling
} def
%
/DoInitialScaling {					% DO INITIAL SCALING
  InitialMatrix setmatrix  72 Resolution div dup scale
} def
%
/PM {		% <paper-height(pix)> <paper-width(pix)> PM
  XP
    /PaperWidth exch def  /PaperHeight exch def
    /Ymax PaperHeight def /PortraitMode true def
    DoInitialScaling
  RP
} def  
%
/SetupLandscape {translate  90 rotate} def
/LM {		% <paper-height(pix)> <paper-width(pix)> LM 
  XP
    /PaperWidth exch def  /PaperHeight exch def
    /Ymax PaperWidth def  /PortraitMode false def
    DoInitialScaling PaperWidth 0 SetupLandscape
  RP
} def  
%
/MAG {						% CHANGE MAGNIFICATION SETTING
  XP  /Magnification exch def  RP
} def
%
/SPB {		%  <xoffset><yoffset>SPB - BEGIN "\SPECIAL" MODE
  Yadjust /Yorigin exch def /Xorigin exch def
  currentrgbcolor Colorsused
  GlobalMode Xorigin Yorigin translate
  Resolution 72 div dup scale			% RESTORE DEFAULT SCALING
  Magnification 1000 div dup scale		% ADJUST FOR ANY MAGNIFICATION
  /Xpos Xpos 72 Resolution div mul 1000 Magnification div mul def
  /Ypos Ypos 72 Resolution div mul 1000 Magnification div mul def
  /spsavobj save def	%SAVE STATE & STACK DEPTH FOR CLEANUP AFTER FIGURE
  /showpage {} def	%DISABLE DURING FIGURE; `RESTORE' WILL BLOW DEF AWAY
  /DEC$EDMS_setrgbcolor /setrgbcolor load def	% save standard definition
  /setrgbcolor {				% create new definition
    /DEC$EDMS_SEPARATE_COLORS where		% if separating colors
    { pop DEC$EDMS_SEPARATE_COLORS 0 ne		% and not on color pass 0
      { pop pop pop 1 1 1 } if			% ...then write white
     } if
    DEC$EDMS_setrgbcolor			% set color as now specified
  } def
  /DEC$EDMS_image /image load def		% save standard definition
  /image {					% create new definition
    /DEC$EDMS_SEPARATE_COLORS where		% if separating colors
    { pop DEC$EDMS_SEPARATE_COLORS 0 ne		% and not on color pass 0
      { gsave					% ...save current device state
        nulldevice				% ...make no marks
        DEC$EDMS_image				% ...process the image
        grestore				% ...restore old device state
      }
      { DEC$EDMS_image } ifelse			% if on color pass 0 - image
    }
    { DEC$EDMS_image } ifelse			% if not separating colors - image
  } def  mark
} def
%
/SPE {		% SPE - END "\SPECIAL" MODE
  cleartomark
  spsavobj restore 
  1000 Magnification div dup scale	% UN-ADJUST FOR ANY MAGNIFICATION
  72 Resolution div dup scale		% RESTORE DEFAULT INTERNAL SCALING
  LocalMode
  /Colorsused exch def setrgbcolor
} def
%
/PP
%
% If DEC$EDMS_MAKE_FILM is defined, it will add the crop & alignment marks,
% and the document name, page number, & ink color identifiers to the page.
%
% Formal Arguments:	None
%
% Referenced Variables: DocumentName
%			Colorsused
%			Currentpagecount
% 			DEC$EDMS_MAKE_FILM
%
% Referenced Procedures: AlignMark
%
% Side Effects: Leaves the current font as Helvetica 8 point.
%		Creates the variable "junkstr".
%
{ /PageNumber exch def
  /DEC$EDMS_MAKE_FILM where					% if making film...
  { pop 2 DEC$EDMS_SEPARATE_COLORS exp cvi Colorsused and 0 ne	% and
if the correct separation
    { /Helvetica findfont 400 scalefont setfont
      20 setlinewidth 0 setgray
      PaperWidth 150 add PaperHeight 100 add moveto		% show the ink color
      (Ink: ) show DEC$EDMS_COLOR_NAMES DEC$EDMS_SEPARATE_COLORS get show
      PaperWidth 150 add PaperHeight 600 add moveto
      (Page: ) show						% show
the page number
      /junkstr 4 string def PageNumber junkstr cvs show
      ( of ) show DEC$EDMS_TOTAL_PAGES junkstr cvs show
      150 PaperHeight 100 add moveto				% show
the document name
      (Document: ) show DEC$EDMS_DOCUMENT_ID show
      150 -500 moveto 						% show
ownership text
      (This film is the property of Digital Equipment Corporation) show stroke

      /mask 15							% all
crop marks on by default
      /DEC$EDMS_SUPPRESS_CROPMARKS where			
% if defined, xor in the suppression mask
          { pop DEC$EDMS_SUPPRESS_CROPMARKS xor } if def

      mask 1 and 1 eq
        { PaperWidth PaperHeight moveto				% Upper Right
          450 0 rmoveto 1350 0 rlineto -1800 1800 rmoveto 0 -1350 rlineto } if

      mask 2 and 2 eq
        { PaperWidth 0 moveto					% Lower Right
          450 0 rmoveto 1350 0 rlineto -1800 -1800 rmoveto 0 1350 rlineto } if

      mask 4 and 4 eq
        { 0 0 moveto						% Lower Left
          -450 0 rmoveto -1350 0 rlineto 1800 -1800 rmoveto 0 1350 rlineto } if

      mask 8 and 8 eq
        { 0 PaperHeight moveto					% Upper Left
          -450 0 rmoveto -1350 0 rlineto 1800 1800 rmoveto 0 -1350 rlineto } if
      stroke

      /mask 15							% all
registration marks on by default
      /DEC$EDMS_SUPPRESS_REGMARKS where				% if
defined, xor in the suppression mask
          { pop DEC$EDMS_SUPPRESS_REGMARKS xor } if def

      mask 1 and 1 eq						% Top Center
         { gsave PaperWidth 2 div PaperHeight
	   /DEC$EDMS_POSITION_REGMARKS where
	     { pop DEC$EDMS_POSITION_REGMARKS -50 mul add } if
	   translate AlignMark grestore } if

      mask 2 and 2 eq						% Right Center
        { gsave PaperWidth
	 /DEC$EDMS_POSITION_REGMARKS where
	  { pop DEC$EDMS_POSITION_REGMARKS -50 mul add } if
	  PaperHeight 2 div translate AlignMark grestore } if

      mask 4 and 4 eq						% Bottom Center
        { gsave PaperWidth 2 div 0
	 /DEC$EDMS_POSITION_REGMARKS where
	  { pop DEC$EDMS_POSITION_REGMARKS 50 mul add } if
	 translate AlignMark grestore } if

      mask 8 and 8 eq						% Left Center
        { gsave 0
	 /DEC$EDMS_POSITION_REGMARKS where
	  { pop DEC$EDMS_POSITION_REGMARKS 50 mul add } if
	 PaperHeight 2 div translate AlignMark grestore } if
      showpage
    }
    { erasepage } ifelse
  }
  { showpage } ifelse
} def
/CLRP {erasepage} def
%
/DMF {		%  /font-name <point-size(pix)> DMF
  /psz exch def  /nam exch def  nam findfont psz scalefont setfont
} def
%
/concatnam {	%  /abcd (xxx) concatnam  ==> /abcdxxx
  /xxx exch def  /nam exch def
  /namstr nam cvsstr cvs def
  /newnam namstr length xxx length add string def
  newnam 0 namstr putinterval
  newnam namstr length xxx putinterval
  newnam cvn 
} def
%
/strip {	%  /abcdef 2 strip ==> /cdef
  /num exch def  /nam exch def
  /namstr nam cvsstr cvs def
  /newlen namstr length num sub def
  namstr num newlen getinterval  cvn
} def
%		ROUTINES TO HANDLE PACKING/UNPACKING NUMBERS
/PackHW {	% <target> <pos> <num> PackHW --> <new target>
  /num exch def  /pos exch def  /target exch def
  num 16#0000FFFF and 1 pos sub 16 mul bitshift  target or
} def
/PackByte {	% <target> <pos> <num> PackByte --> <new target>
  /num exch def  /pos exch def  /target exch def
  num 16#000000FF and 3 pos sub 8 mul bitshift   target or
} def
/UnpkHW {	%  <pos> <num> UnpkHW --> <unpacked value>
  /num exch def  /pos exch def
  num 1 pos sub -16 mul bitshift 16#0000FFFF and
  dup 16#00007FFF gt {16#00010000 sub} if
} def
/UnpkByte {	%  <pos> <num> UnpkByte --> <unpacked value>
  /num exch def  /pos exch def
  num 3 pos sub -8 mul bitshift 16#000000FF and
  dup 16#0000007F gt {16#00000100 sub} if
} def
%
/DPSF {		% /procname size /fontname DPSF
    findfont exch scalefont
    [ exch /setfont cvx ] cvx def
} bind def
%
/PXLBuildCharDict 17 dict def
/CMEncodingArray 256 array def
0 1 255 {CMEncodingArray exch dup cvsstr cvs cvn put} for
/RasterConvert {RasterScaleFactor div} def
/TransformBBox {
  aload pop
  /BB-ury exch def  /BB-urx exch def  /BB-lly exch def  /BB-llx exch def
  [ BB-llx RasterConvert BB-lly RasterConvert 
    BB-urx RasterConvert BB-ury RasterConvert ]
} def
/RunLengthToRasters {
  % none yet
} def
/GenerateRasters {			% GENERATE RASTERS FOR "IMAGEMASK"
  rasters  runlength 1 eq {RunLengthToRasters} if
} def
%
/int-dict-name {int (-dict) concatnam} def
/int-dict {int (-dict) concatnam cvx load} def
%
/DefinePXLFont {
	%  <int-font-name><ext-font-name><pt-sz(pix)><PXL mag><num-chars>...
	%  ...[llx lly urx ury]<newfont-fg>DefinePXLFont
  /newfont exch def  /bb exch def      /num exch def  /psz exch def
  /dsz exch def      /pxlmag exch def  /ext exch def  /int exch def
  /fnam ext (-) concatnam pxlmag cvsstr cvs concatnam def
  newfont not {
    int-dict-name 13 dict def
    int-dict begin
      /FontType 3 def  /FontMatrix [ 1 dsz div 0 0 1 dsz div 0 0 ] def
      /FontBBox bb TransformBBox def  /Encoding CMEncodingArray def
      /CharDict 1 dict def  CharDict begin  /Char-Info num array def  end
      /BuildChar {
        PXLBuildCharDict begin
          /char exch def  /fontdict exch def
          fontdict /CharDict get /Char-Info get char get aload pop
          /rasters exch def  /PackedWord1 exch def
          0 PackedWord1 UnpkHW 16#7FFF ne {
	    /PackedWord2 exch def  /wx 0 PackedWord1 UnpkHW def
            /rows 2 PackedWord1 UnpkByte def  /cols 3 PackedWord1 UnpkByte def
            /llx 0 PackedWord2 UnpkByte def   /lly 1 PackedWord2 UnpkByte def
            /urx 2 PackedWord2 UnpkByte def   /ury 3 PackedWord2 UnpkByte def
	  }{ %else
	    /PackedWord2 exch def  /PackedWord3 exch def  /PackedWord4 exch def
            /wx 1 PackedWord1 UnpkHW def    /rows 0 PackedWord2 UnpkHW def
            /cols 1 PackedWord2 UnpkHW def  /llx 0 PackedWord3 UnpkHW def
            /lly 1 PackedWord3 UnpkHW def   /urx 0 PackedWord4 UnpkHW def
            /ury 1 PackedWord4 UnpkHW def
          } ifelse
          rows 0 lt {
	    /rows rows neg def /runlength 1 def
	  }{ %else
	    /runlength 0 def
	  } ifelse
          wx 0
          llx RasterConvert lly RasterConvert 
          urx RasterConvert ury RasterConvert setcachedevice
          rows 0 ne {
	    gsave
	      cols rows true  RasterScaleFactor 
              0 0 RasterScaleFactor neg llx .5 add neg ury .5 add 
              tempmatrix astore  GenerateRasters imagemask
            grestore
          } if
        end
      } def
    end
    fnam int-dict definefont pop 
  } if 
  int-dict-name fnam findfont psz scalefont def
  currentdict int [ int-dict /setfont cvx ] cvx put
} def 
/PXLF { true  DefinePXLFont} def	% SIGNAL THAT FONT IS ALREADY LOADED
/PXLNF {false  DefinePXLFont} def	% SIGNAL THAT FONT IS NOT ALREADY LOADED
%
/PXLC {	% <int-font-name><code><wx><llx><lly><urx><ury>...
	% ...<rows><cols><runlength><rasters>PXLC
  /rasters exch def  /runlength exch def  /cols exch def  /rows exch def
  /ury exch def      /urx exch def        /lly exch def   /llx exch def
  /wx exch def       /code exch def       /int exch def
  % SEE IF LONG OR SHORT FORMAT IS REQUIRED
  true cols CKSZ rows CKSZ ury CKSZ urx CKSZ lly CKSZ llx CKSZ 
  TackRunLengthToRows {
    int-dict /CharDict get /Char-Info get code 
    [ 0 0 llx PackByte 1 lly PackByte 2 urx PackByte 3 ury PackByte
      0 0 wx PackHW 2 rows PackByte 3 cols PackByte rasters ] put
  }{ %else
    int-dict /CharDict get /Char-Info get code 
    [ 0 0 urx PackHW 1 ury PackHW   0 0 llx PackHW 1 lly PackHW
      0 0 rows PackHW 1 cols PackHW 0 0 16#7FFF PackHW 1 wx PackHW rasters ] put
  } ifelse
} def
%
/CKSZ {abs 127 le and} def
/TackRunLengthToRows {runlength 0 ne {/rows rows neg def} if} def
%
/PLOTC {
  % <wx><dsz><psz><llx><lly><urx><ury><rows><cols><runlength><rasters>PLOTC
  /rasters exch def  /runlength exch def  /cols exch def  /rows exch def
  /ury exch def      /urx exch def        /lly exch def   /llx exch def
  /psz exch def      /dsz exch def        /wx exch def
  % "PLOT" A CHARACTER'S RASTER PATTERN
  rows 0 ne {
    gsave
      currentpoint translate  psz dsz div dup scale
      cols rows true  RasterScaleFactor 0 0 RasterScaleFactor 
      neg llx .5 add neg ury .5 add  tempmatrix astore
      GenerateRasters imagemask
    grestore
  } if
  wx x
} def
%
/AlignMark
%
% This procedure draws an alignment mark centered on the coordinate system
% origin. If the variable DEC$EDMS_SEPARATE_COLORS = 0 then a "positive"
% alignment mark is drawn. If DEC$EDMS_SEPARATE_COLORS <> 0 then a "negative"
% alignment mark is drawn. 
%
% Formal Arguments: NONE
%
% Referenced Variables: DEC$EDMS_SEPARATE_COLORS
%
% Referenced Procedures: NONE
%
% Side Effects: NONE
%
{ DEC$EDMS_SEPARATE_COLORS 0 eq
  { 0 0 300 0 360 arc
    0 -450 moveto 0 450 lineto -450 0 moveto 450 0 lineto stroke }
  { 0 0 450 0 360 arc fill 1 setgray 0 0 300 0 360 arc 
    0 -450 moveto 0 450 lineto -450 0 moveto 450 0 lineto stroke 0 setgray }
  ifelse
} bind def


/SC
% If not making film, the following procedure sets the current color using the
% RGB color model. If making film, the procedure notes the "color pass" and,
% if the specified color index matches the color pass, subsequent marks are
% written in black. If the specified color index does not match the color pass,
% marks are written in white. Use of colors on individual pages is also tracked
% to allow pages that don't use a particular color to be suppressed on that
% color pass (by the code in the /PP routine).
%
% Formal Arguments: color index (on stack)
%
% Referenced Variables: Colorsused
%			DEC$EDMS_SEPARATE_COLORS
%			DEC$EDMS_SUPPRESS_COLOR
%
% Referenced Procedures: NONE
%
% Side Effects: Modifies the variable Colorsused to record use of the color.
%
{ /DEC$EDMS_SUPPRESS_COLOR where		% if suppressing color
  { pop 0 setgray pop }				% .then set "color" to Black 
  { /DEC$EDMS_SEPARATE_COLORS where		% .else if separating colors
    { pop dup DEC$EDMS_SEPARATE_COLORS eq	% ..and if on this color pass
      { 0 setgray /Colorsused Colorsused	% ...then write black (do write)
        2 3 index exp cvi or def }		% ...and note use of the "color"
      { 1 setgray } ifelse pop }		% ...else write white (don't write)
    { dup (  ) cvs dup length 15 add string     % ..using the color index,
      /tstr exch def                            % ..build up the name of the
      tstr 0 (DEC$EDMS_COLOR_) putinterval      % ..potential external color
      tstr exch 15 exch putinterval             % ..name procedure
      tstr cvn where                            % ..and see if it is defined
      { pop pop tstr cvn cvx exec }             % ...if it is, execute it
      { DEC$EDMS_COLOR_ARRAY exch get		% ..else execute the internal
        exec } ifelse				% ..color setting procedure
    } ifelse
  } ifelse
} def

/RV                                          % .. gross recto/verso translate
{ /DEC$EDMS_ENABLE_RECTOVERSO where
      { pop
	/RVmatrix DEC$EDMS_ENABLE_RECTOVERSO 50 mul 0 matrix translate def
	RVmatrix concat
      } if
} def

end  %DEC_DVC$dict
%%EndProlog
%%BeginSetup
/DEC$EDMS_MAKE_FILM where	% if we are making film...
 { pop				% ..clean up the stack
   54 dup translate		% ..make room for the film info
 } if
BeginDVC$PSDoc
/PaperWidth 8.500 Resolution mul def
/PaperHeight 11.000 Resolution mul def
/Ymax PaperHeight def
CLRP 300 3600 RES
%>  Postamble of file DISK_LINN:[000000.DSSA]API_FORMATTED.DVI_PS.
% DefineFont:F147 Category:10 Pointsize:11
/NewCenturySchlbk-Roman /NewCenturySchlbk-Roman@DOCPSE DOCPSE ReENCODE
/F147 550.0 /NewCenturySchlbk-Roman@DOCPSE DPSF
% DefineFont:F40 Category:10 Pointsize:9
/Helvetica-Bold /Helvetica-Bold@DOCPSE DOCPSE ReENCODE
/F40 450.0 /Helvetica-Bold@DOCPSE DPSF
% DefineFont:F36 Category:10 Pointsize:10
/F36 500.0 /Helvetica-Bold@DOCPSE DPSF
% DefineFont:F32 Category:10 Pointsize:11
/F32 550.0 /Helvetica-Bold@DOCPSE DPSF
% DefineFont:F28 Category:10 Pointsize:12
/F28 600.0 /Helvetica-Bold@DOCPSE DPSF
% DefineFont:F24 Category:10 Pointsize:14
/F24 700.0 /Helvetica-Bold@DOCPSE DPSF
%%BeginDEC$EDMSInfo
/DEC$EDMS_DOCUMENT_ID () def
/DEC$EDMS_COLOR_NAMES [ (BLACK) (BLACK) (BLACK) (BLACK) ] def
/DEC$EDMS_COLOR_ARRAY [
  { 0 setgray }         %color 0 procedure
  { 0 setgray }         %color 1 procedure
  { 0 setgray }         %color 2 procedure
  { 0 setgray }         %color 3 procedure
] def
/DEC$EDMS_TOTAL_PAGES 0 def
%%EndDEC$EDMSInfo
/DEC$EDMS_MAKE_FILM where
{ pop /DEC$EDMS_SEPARATE_COLORS where
  { pop }
  { (ERROR - DEC$EDMS_MAKE_FILM requires DEC$EDMS_SEPARATE_COLORS be
defined) = quit } ifelse
} if
/DEC$EDMS_SEPARATE_COLORS where
{ pop /DEC$EDMS_SUPPRESS_COLOR where
  { pop (ERROR - DEC$EDMS_SEPARATE_COLORS and DEC$EDMS_SUPPRESS_COLOR
are mutually exclusive) = quit } if
  DEC$EDMS_SEPARATE_COLORS 1 gt { (ERROR - No such color used in this
file) = quit } if
} if
/DVC$PSFonts save def
%%EndSetup
%
%%Page: 1 1
%%BeginPageSetup
%%EndPageSetup
%%PageFonts: (atend)
%%PageCustomColors: (atend)
1000 BP PaperHeight PaperWidth PM 0 0 XY 
%%BeginCustomColor: 0 
0 SC 14196 4006 XY F147(John)S 262 x(Linn)S 13508 X 648 y(Secure)S 259 x
(Systems)S 11497 X 647 y(Digital)S 242 x(Equi)S -2 x(pment)S 242 x(Corporation)S
11445 X 648 y(85)S 241 x(Swanson)S 241 x(Road,)S 256 x(BXB1)S -2 x(-2/D04)S
11796 X 648 y(Boxborough,)S 260 x(MA)S 245 x(0171)S -2 x(9-1326)S 10353 X
647 y(Linn@ultra.enet.dec.com;)S 259 x(UL)S -30 x(TRA::LINN)S 6215 8539 XY
F24(Generic)S 255 x(Security)S 255 x(Service)S 255 x(Application)S 255 x
(Program)S 256 x(Interface)S 3899 9585 XY F28(1)S 598 x(API)S 199 x
(Characteristics)S 3899 10582 XY F147(This)S 166 x(Appl)S -2 x(ication)S
166 x(Program)S 168 x(Interface)S 167 x(\(API\))S 167 x(de\211nition)S
165 x(provides)S 166 x(security)S 166 x(services)S 167 x(to)S 166 x
(calling)S 166 x(ap-)S 3899 X 647 y(plicati)S -2 x(ons)S 246 x(in)S
245 x(a)S 246 x(generic)S 246 x(fashion,)S 261 x(supp)S -2 x(ortable)S
245 x(with)S 246 x(a)S 246 x(range)S 246 x(of)S 246 x(underlying)S 245 x
(mechanisms)S 244 x(and)S 3899 X 648 y(technologies)S 246 x(and)S 246 x
(hence)S 248 x(all)S -2 x(owing)S 248 x(portabi)S -2 x(lity)S 247 x
(of)S 248 x(appl)S -2 x(ications)S 246 x(to)S 248 x(different)S 247 x
(environments.)S 437 x(It)S 3899 X 647 y(separates)S 169 x(the)S 170 x
(operations)S 168 x(of)S 171 x(initia)S -2 x(lizing)S 169 x(a)S 170 x
(security)S 170 x(context)S 171 x(between)S 170 x(peers,)S 172 x(achieving)S
169 x(peer)S 170 x(en-)S 3899 X 648 y(tity)S 194 x(authentication)S
193 x(\(Init_sec_context)S(\()S 84 x(\))S 194 x(and)S 193 x(Accept_sec_context)S
(\()S 84 x(\))S 194 x(calls\),)S 197 x(from)S 195 x(the)S 194 x(operations)S
3899 X 648 y(of)S 137 x(providing)S 136 x(data)S 137 x(origin)S 136 x
(authentication)S 136 x(and)S 136 x(integrity)S 137 x(protection)S 137 x
(\(Sign)S(\()S 84 x(\))S 137 x(and)S 136 x(V)S -50 x(erify)S(\()S 84 x
(\))S 137 x(calls\))S 137 x(for)S 3899 X 647 y(messages)S 206 x(subsequ)S
- -2 x(ently)S 207 x(transferred)S 208 x(in)S 206 x(that)S 207 x(context.)S
319 x(It)S 207 x(also)S 206 x(supports)S 206 x(provision)S 206 x(of)S
208 x(con\211den-)S 3899 X 648 y(tiali)S -2 x(ty)S 162 x(services)S
162 x(\(with)S 161 x(Seal)S(\()S 83 x(\))S 162 x(and)S 161 x(Unseal)S
- -2 x(\()S 84 x(\))S 162 x(calls)S -2 x(\))S 162 x(in)S 161 x(additi)S
- -2 x(on)S 162 x(to)S 161 x(the)S 162 x(data)S 160 x(origin)S 161
x(authentication)S
3899 X 647 y(and)S 181 x(integrity)S 183 x(security)S 183 x(services.)S
3899 17257 XY F32(1.1)S 547 x(Security)S 183 x(Contexts)S 182 x(and)S
182 x(Relation)S 182 x(to)S 183 x(Protocols)S 3899 18253 XY F147(Security)S
257 x(contexts)S 256 x(are)S 256 x(establis)S -2 x(hed)S 256 x(between)S
256 x(peers,)S 274 x(using)S 256 x(credential)S -2 x(s)S 256 x(establis)S
- -2 x(hed)S 256 x(locally)S 255 x(in)S 3899 X 647 y(conjunction)S 171 x
(with)S 171 x(each)S 172 x(peer)S 171 x(or)S 172 x(received)S 171 x
(by)S 172 x(peers)S 171 x(via)S 171 x(delegati)S -2 x(on.)S 240 x(Multiple)S
170 x(contexts)S 172 x(may)S 172 x(exist)S 3899 X 648 y(simultan)S -2 x
(eously)S 144 x(between)S 145 x(a)S 144 x(pair)S 144 x(of)S 145 x(peers,)S
153 x(usin)S -2 x(g)S 145 x(the)S 145 x(same)S 144 x(or)S 145 x(different)S
145 x(credentials.)S 230 x(Coexistence)S 3899 X 648 y(of)S 156 x(multipl)S
- -2 x(e)S 156 x(contexts)S 155 x(using)S 155 x(different)S 156 x(credentials)S
154 x(allows)S 154 x(graceful)S 156 x(rollover)S 155 x(when)S 156 x
(credentials)S 154 x(ex-)S 3899 X 647 y(pire.)S 232 x(Distinction)S
150 x(among)S 150 x(multiple)S 149 x(contexts)S 151 x(based)S 149 x
(on)S 150 x(the)S 151 x(same)S 150 x(credentials)S 149 x(serves)S 150 x
(appli)S -2 x(cations)S 3899 X 648 y(by)S 182 x(distingui)S -2 x(shing)S
182 x(different)S 183 x(message)S 182 x(streams)S 182 x(in)S 182 x(a)S
183 x(security)S 182 x(sense.)S 3899 22487 XY(This)S 188 x(API)S 189 x
(is)S 189 x(indep)S -2 x(endent)S 188 x(of)S 190 x(underlyi)S -2 x(ng)S
189 x(protocols)S 189 x(and)S 188 x(add)S -2 x(ressing)S 189 x(structure,)S
191 x(and)S 188 x(depend)S -2 x(s)S 189 x(on)S 3899 X 648 y(its)S 153 x
(callers)S 152 x(to)S 154 x(transport)S 153 x(API-provided)S 152 x(data)S
153 x(elements.)S 233 x(As)S 153 x(a)S 153 x(result)S 153 x(of)S 154 x
(these)S 153 x(factors,)S 160 x(it)S 153 x(is)S 153 x(a)S 153 x(caller)S
3899 X 647 y(responsi)S -2 x(bility)S 163 x(to)S 163 x(parse)S 163 x
(communicated)S 163 x(messages,)S 166 x(separating)S 162 x(API-related)S
163 x(data)S 163 x(elements)S 163 x(from)S 3899 X 648 y(caller)S -11 x
(-provided)S 161 x(data.)S 235 x(The)S 162 x(API)S 161 x(is)S 160 x
(independ)S -2 x(ent)S 161 x(of)S 162 x(connection)S 161 x(vs.)S 236 x
(connectionless)S 160 x(orientation)S 160 x(of)S 3899 X 647 y(the)S
168 x(underlying)S 167 x(communications)S 167 x(service.)S 239 x(It)S
168 x(does)S 167 x(accommodate)S 168 x(the)S 168 x(concept)S 168 x(of)S
169 x(caller)S -11 x(-provided)S 3899 X 648 y(channel)S 228 x(bind)S
- -2 x(ing)S 229 x(information)S 228 x(\("chan_bindi)S -2 x(ngs"\),)S
241 x(tying)S 229 x(security)S 229 x(contexts)S 229 x(to)S 229 x(security-related)S
3899 X 647 y(characteristics)S 210 x(of)S 211 x(that)S 211 x(underlyi)S
- -2 x(ng)S 211 x(service;)S 225 x(the)S 211 x(caller)S 210 x(initia)S
- -2 x(ting)S 211 x(a)S 210 x(security)S 211 x(context)S 211 x(must)S
211 x(de-)S 3899 X 648 y(termine)S 182 x(the)S 183 x(values)S 182 x
(of)S 183 x(such)S 182 x(bind)S -2 x(ings)S 182 x(before)S 183 x(making)S
182 x(the)S 183 x(Init_sec_context)S(\()S 84 x(\))S 183 x(call.)S 3899 28016 XY
(No)S 134 x(correlation)S 134 x(between)S 134 x(security)S 134 x(context)S
135 x(and)S 134 x(communications)S 133 x(protocol)S 134 x(associati)S
- -2 x(on)S 135 x(is)S 133 x(dictated.)S 3899 X 648 y(This)S 154 x(separation)S
153 x(allows)S 153 x(the)S 155 x(API)S 155 x(to)S 154 x(be)S 155 x(used)S
153 x(in)S 154 x(a)S 155 x(wide)S 154 x(range)S 154 x(of)S 155 x(communications)S
154 x(environments,)S 3899 X 647 y(and)S 132 x(also)S 133 x(simpl)S
- -2 x(i\211es)S 133 x(the)S 133 x(calling)S 132 x(sequences)S 133 x(of)S
134 x(the)S 133 x(indi)S -2 x(vidual)S 132 x(calls.)S 227 x(In)S 133 x
(many)S 133 x(cases)S 133 x(\(dependi)S -2 x(ng)S 134 x(on)S 3899 X
648 y(underlyin)S -2 x(g)S 151 x(security)S 150 x(protocol,)S 157 x
(associ)S -2 x(ated)S 150 x(mechanism,)S 156 x(and)S 149 x(availa)S
- -2 x(bility)S 149 x(of)S 151 x(cached)S 149 x(information\),)S 3899 X
648 y(the)S 159 x(state)S 158 x(information)S 158 x(required)S 158 x
(for)S 160 x(context)S 159 x(setup)S 158 x(can)S 159 x(be)S 158 x(sent)S
159 x(concurrently)S 159 x(with)S 159 x(initia)S -2 x(l)S 159 x(signed)S
3899 X 647 y(user)S 182 x(data,)S 182 x(without)S 183 x(interposi)S
- -2 x(ng)S 183 x(addi)S -2 x(tional)S 182 x(message)S 182 x(exchanges.)S
14368 37373 XY F36(28\203February\2031990:)S 221 x(DIGIT)S -36 x(AL)S
166 x(INTERNAL)S 166 x(USE)S 166 x(ONL)S -46 x(Y)S 498 x(1)S
%%EndCustomColor: 0
1 PP EP
%%PageTrailer
%%PageFonts: NewCenturySchlbk-Roman
%%+ Helvetica-Bold
%%PageCustomColors: 0
%
%%Page: 2 2
%%BeginPageSetup
%%EndPageSetup
%%PageFonts: (atend)
%%PageCustomColors: (atend)
1000 BP PaperHeight PaperWidth PM 0 0 XY 
%%BeginCustomColor: 0 
0 SC 4048 2106 XY F40(Linn:)S 199 x(Generic)S 150 x(Security)S 151 x
(Service)S 150 x(API)S 3899 4013 XY F32(1.2)S 547 x(Stat)S 2 x(us)S
182 x(Repo)S -2 x(rting)S 3899 5009 XY F147(Each)S 191 x(API)S 191 x
(call)S 191 x(provides)S 190 x(two)S 192 x(status)S 190 x(returns:)S
262 x(major_status)S 191 x(represents)S 190 x(high-level)S 191 x(information)S
3899 X 647 y(about)S 136 x(the)S 137 x(completion)S 136 x(of)S 137 x
(a)S 137 x(call)S 136 x(\(e.g.,)S 148 x(COMPLETE,)S 138 x(F)S -40 x
(AILURE,)S 136 x(RETR)S -21 x(Y_NEEDED\),)S 137 x(suf\211cient)S 136 x
(to)S 3899 X 648 y(drive)S 185 x(normal)S 185 x(control)S 185 x(\212ow)S
185 x(within)S 185 x(the)S 185 x(caller)S 185 x(in)S 184 x(a)S 185 x
(generic)S 186 x(fashion,)S 185 x(and)S 184 x(minor_status)S 185 x(provides)S
3899 X 648 y(more)S 270 x(detaile)S -2 x(d)S 270 x(status)S 269 x(information)S
269 x(which)S 269 x(may)S 270 x(include)S 269 x(statuses)S 268 x(speci\211c)S
269 x(to)S 270 x(the)S 270 x(underlyi)S -2 x(ng)S 3899 X 647 y(security)S
183 x(mechanis)S -2 x(m.)S 244 x(Minor_status)S 182 x(values)S 182 x
(are)S 182 x(not)S 183 x(speci\211ed)S 181 x(in)S 182 x(this)S 182 x
(document.)S 3899 8595 XY(RETR)S -21 x(Y_NEE)S -2 x(DED)S 126 x(major_status)S
124 x(returns,)S 137 x(and)S 124 x(optiona)S -2 x(l)S 125 x(message)S
124 x(outputs,)S 136 x(are)S 125 x(provided)S 124 x(in)S 124 x(Init_)S
3899 X 648 y(sec_context)S(\()S 84 x(\))S 176 x(and)S 175 x(Accept_sec_context)S
(\()S 84 x(\))S 177 x(so)S 175 x(that)S 176 x(multiple)S 175 x(message)S
175 x(preamble)S 175 x(transactions)S 175 x(\(as)S 3899 X 648 y(are)S
210 x(required,)S 216 x(for)S 211 x(example,)S 216 x(to)S 210 x(authenticate)S
209 x(to)S 210 x(a)S 210 x(Kerberos)S 210 x(V5)S 209 x(double-TGT)S
211 x(service\))S 210 x(need)S 210 x(not)S 3899 X 647 y(be)S 157 x(supp)S
- -2 x(orted)S 158 x(with)S 157 x(separate)S 156 x(code)S 157 x(paths)S
157 x(in)S 156 x(calling)S 156 x(appli)S -2 x(cations.)S 235 x(The)S
158 x(same)S 156 x(mechanism)S 157 x(is)S 156 x(used)S 3899 X 648 y
(to)S 183 x(encapsu)S -2 x(late)S 182 x(mutual)S 182 x(authentication)S
181 x(within)S 182 x(the)S 183 x(API')S -21 x(s)S 183 x(context)S 183 x
(initia)S -2 x(tion)S 182 x(calls.)S 3899 12182 XY(API)S 147 x(calls)S
146 x(return)S 147 x(once)S 147 x(local)S 146 x(processing)S 146 x(is)S
147 x(complete,)S 154 x(and)S 146 x(do)S 146 x(not)S 147 x(pend)S 146 x
(on)S 147 x(seriali)S -2 x(zed)S 146 x(interactions)S 3899 X 648 y(with)S
251 x(peer)S 250 x(entities.)S 448 x(As)S 250 x(a)S 250 x(result,)S
268 x(local)S 250 x(API)S 251 x(status)S 250 x(returns)S 251 x(cannot)S
250 x(re\212ect)S 252 x(unpred)S -2 x(ictable)S 250 x(or)S 3899 X 647 y
(asynchronous)S 134 x(exceptions)S 135 x(occurring)S 136 x(at)S 135 x
(remote)S 136 x(peers,)S 144 x(and)S 135 x(re\212ection)S 135 x(of)S
136 x(such)S 135 x(status)S 134 x(information)S 3899 X 648 y(is)S 182 x
(a)S 182 x(caller)S 182 x(responsib)S -2 x(ility)S 182 x(outside)S 182 x
(the)S 182 x(API.)S 3899 15619 XY F32(1.3)S 547 x(Naming)S 3899 16615 XY
F147(As)S 170 x(far)S 171 x(as)S 170 x(the)S 170 x(interface)S 171 x
(is)S 170 x(concerned,)S 173 x(authenticated)S 169 x(names)S 170 x(are)S
170 x(opaque)S 169 x(strings)S 170 x(with)S 170 x(no)S 171 x(struc-)S
3899 X 648 y(ture)S 230 x(dictated.)S 386 x(It)S 231 x(must)S 230 x
(be)S 230 x(recognized,)S 242 x(however)S -40 x(,)S 242 x(that)S 231 x
(underlyi)S -2 x(ng)S 231 x(security)S 230 x(mechanisms)S 229 x(will)S
3899 X 647 y(impose)S 195 x(constraints)S 195 x(on)S 196 x(naming)S
196 x(representations)S -2 x(.)S 285 x(T)S -33 x(ransla)S -2 x(tion)S
196 x(between)S 196 x(different)S 197 x(naming)S 195 x(rep-)S 3899 X
648 y(resentations)S 144 x(is)S 145 x(a)S 145 x(function)S 146 x(outsid)S
- -2 x(e)S 146 x(the)S 145 x(scope)S 145 x(of)S 146 x(this)S 145 x(interface,)S
153 x(and)S 145 x(supp)S -2 x(ort)S 146 x(by)S 146 x(local)S 144 x(OS-speci\211c)S
3899 X 648 y(functions)S 163 x(is)S 163 x(anticipa)S -2 x(ted)S 164 x
(to)S 163 x(map)S 163 x(between)S 164 x(appl)S -2 x(ication-visib)S
- -2 x(le)S 164 x(forms)S 164 x(and)S 163 x(conventions)S 163 x(of)S 164 x
(under-)S 3899 X 647 y(lying)S 175 x(security)S 176 x(mechanisms)S -2 x
(.)S 242 x(Use)S 175 x(of)S 176 x(a)S 175 x(common)S 176 x(hierarchic)S
175 x(naming)S 175 x(format)S 176 x(would)S 175 x(aid)S 175 x(in)S 175 x
(devel-)S 3899 X 648 y(opment)S 156 x(of)S 157 x(portable)S 155 x(appl)S
- -2 x(ications,)S 161 x(but)S 156 x(selection)S 156 x(or)S 157 x(speci\211)S
- -2 x(cation)S 156 x(of)S 157 x(such)S 156 x(a)S 156 x(format)S 158 x
(is)S 155 x(outside)S 156 x(the)S 3899 X 647 y(scope)S 182 x(of)S 183 x
(this)S 182 x(API;)S 183 x(we)S 183 x(recommend)S 183 x(that)S 182 x
(it)S 182 x(be)S 183 x(considered)S 181 x(in)S 182 x(other)S 183 x(forums.)S
3899 22643 XY F32(1.4)S 547 x(Mechanism)S 182 x(T)S -41 x(ypes)S 3899 23639 XY
F147(In)S 228 x(order)S 229 x(to)S 228 x(initiate)S 227 x(a)S 229 x
(security)S 228 x(context)S 229 x(with)S 229 x(a)S 228 x(target)S 229 x
(peer)S -41 x(,)S 240 x(it)S 229 x(is)S 227 x(necessary)S 228 x(to)S
229 x(determine)S 228 x(an)S 3899 X 648 y(approp)S -2 x(riate)S 178 x
(underlying)S 177 x(mechanism)S 178 x(type)S 178 x(\(mech_type\))S 179 x
(shared)S 177 x(with)S 178 x(that)S 178 x(peer)S -41 x(.)S 243 x(In)S
178 x(some)S 178 x(cases,)S 3899 X 647 y(mech_type)S 139 x(determinati)S
- -2 x(ons)S 139 x(may)S 138 x(be)S 139 x(made)S 138 x(through)S 138 x
(syntactic)S 139 x(convention)S 138 x(by)S 139 x(examining)S 138 x(a)S
138 x(target)S 3899 X 648 y(name;)S 166 x(in)S 157 x(other)S 157 x(cases,)S
163 x(a)S 157 x(databa)S -2 x(se)S 158 x(or)S 157 x(naming)S 157 x(service)S
158 x(attribute)S 157 x(lookup)S 156 x(may)S 158 x(be)S 157 x(needed)S
156 x(in)S 157 x(order)S 3899 X 647 y(to)S 131 x(provide)S 131 x(mech_type)S
131 x(information)S 130 x(corresponding)S 131 x(to)S 131 x(a)S 131 x
(provided)S 130 x(name.)S 226 x(It)S 131 x(is)S 131 x(recommended)S
131 x(that)S 3899 X 648 y(callers)S 165 x(initiatin)S -2 x(g)S 167 x
(contexts)S 167 x(use)S 166 x(a)S 166 x(default)S 166 x(mech_type)S
166 x(value,)S 170 x(all)S -2 x(owing)S 167 x(system-speci\211c)S 166 x
(functions)S 3899 X 647 y(below)S 178 x(the)S 178 x(API)S 179 x(to)S
179 x(select)S 178 x(the)S 178 x(appropria)S -2 x(te)S 179 x(mech_type,)S
180 x(but)S 178 x(callers)S 177 x(may)S 179 x(direct)S 178 x(that)S
178 x(a)S 179 x(particula)S -2 x(r)S 3899 X 648 y(mech_type)S 169 x
(be)S 169 x(employed)S 168 x(when)S 168 x(necessary)S -61 x(.)S 239 x
(The)S 170 x(set)S 169 x(of)S 169 x(mech_types)S 169 x(which)S 169 x
(an)S 168 x(entity)S 169 x(may)S 169 x(assert)S 3899 X 648 y(as)S 194 x
(an)S 194 x(initiator)S 194 x(in)S 194 x(establi)S -2 x(shing)S 194 x
(contexts)S 195 x(to)S 195 x(others)S 195 x(need)S 194 x(not)S 194 x
(be)S 195 x(the)S 195 x(same)S 194 x(as)S 194 x(the)S 195 x(set)S 194 x
(of)S 195 x(mech_)S 3899 X 647 y(types)S 182 x(with)S 183 x(which)S
182 x(it)S 182 x(can)S 183 x(accept)S 182 x(incoming)S 182 x(contexts)S
183 x(from)S 184 x(others.)S 3899 30463 XY(A)S 162 x(registry)S 164 x
(of)S 163 x(mech_type)S 163 x(identi\211)S -2 x(ers)S 163 x(is)S 162 x
(needed)S 162 x(in)S 162 x(order)S 163 x(to)S 163 x(preclude)S 162 x
(ambiguous)S 161 x(interpretation.)S 3899 X 648 y(This)S 155 x(document)S
156 x(does)S 155 x(not)S 155 x(enumerate)S 156 x(the)S 155 x(set)S 156 x
(of)S 156 x(mech_types)S 156 x(which)S 155 x(may)S 156 x(support)S 155 x
(API)S 156 x(functions.)S 3899 37373 XY F36(2)S 498 x(28\203February\2031990:)S
221 x(DIGIT)S -36 x(AL)S 166 x(INTERNAL)S 166 x(USE)S 166 x(ONL)S -46 x
(Y)S
%%EndCustomColor: 0
2 PP EP
%%PageTrailer
%%PageFonts: Helvetica-Bold NewCenturySchlbk-Roman
%%PageCustomColors: 0
%
%%Page: 3 3
%%BeginPageSetup
%%EndPageSetup
%%PageFonts: (atend)
%%PageCustomColors: (atend)
1000 BP PaperHeight PaperWidth PM 0 0 XY 
%%BeginCustomColor: 0 
0 SC 19687 2106 XY F40(Linn:)S 199 x(Generic)S 150 x(Security)S 151 x
(Service)S 150 x(API)S 3899 4013 XY F32(1.5)S 547 x(Replay)S 182 x(Detection)S
182 x(and)S 182 x(Sequencing)S 3899 5009 XY F147(Certain)S 252 x(underlying)S
253 x(mech_types)S 253 x(are)S 253 x(expected)S 253 x(to)S 253 x(offer)S
255 x(support)S 252 x(for)S 254 x(replay)S 253 x(detection)S 253 x(and/or)S
3899 X 647 y(sequencin)S -2 x(g)S 232 x(of)S 232 x(messages)S 231 x
(transferred)S 231 x(on)S 232 x(the)S 231 x(contexts)S 232 x(they)S
232 x(supp)S -2 x(ort.)S 391 x(The)S 232 x(caller)S 231 x(initia)S -2 x
(ting)S 232 x(a)S 3899 X 648 y(context)S 233 x(provides)S 232 x(\212ags)S
232 x(\(replay_det_req_\212ag)S 232 x(and)S 232 x(sequence_req_\212a)S
- -2 x(g\))S 234 x(to)S 233 x(specify)S 232 x(whether)S 234 x(the)S 3899 X
648 y(use)S 157 x(of)S 158 x(such)S 158 x(features)S 158 x(is)S 157 x
(desired)S 156 x(on)S 158 x(the)S 157 x(context)S 159 x(being)S 157 x
(establi)S -2 x(shed.)S 235 x(The)S 158 x(API)S 158 x(implementa)S -2 x
(tion)S 158 x(at)S 3899 X 647 y(the)S 158 x(initiator)S 158 x(system)S
158 x(can)S 158 x(determine)S 158 x(whether)S 159 x(these)S 158 x(features)S
159 x(are)S 158 x(supported)S 157 x(\(and)S 158 x(whether)S 159 x(they)S
3899 X 648 y(are)S 178 x(optiona)S -2 x(lly)S 177 x(selectable\))S 177 x
(as)S 177 x(a)S 178 x(function)S 177 x(of)S 179 x(mech_type,)S 179 x
(without)S 177 x(need)S 177 x(for)S 179 x(bil)S -2 x(ateral)S 178 x
(negotiation)S 3899 X 647 y(with)S 182 x(the)S 183 x(target.)S 3899 9891 XY
(As)S 157 x(the)S 158 x(message)S 158 x(stream)S 158 x(integrity)S 158 x
(features)S 159 x(\(especial)S -2 x(ly)S 158 x(sequencing\))S 158 x
(may)S 158 x(interfere)S 159 x(with)S 158 x(certain)S 3899 X 647 y(appl)S
- -2 x(ications')S 253 x(intended)S 253 x(communications)S 253 x(paradi)S
- -2 x(gms,)S 273 x(it)S 254 x(is)S 254 x(highly)S 253 x(recommended)S
254 x(that)S 254 x(mech_)S 3899 X 648 y(types)S 219 x(supportin)S -2 x
(g)S 220 x(these)S 219 x(features)S 220 x(allow)S 219 x(them)S 219 x
(to)S 220 x(be)S 219 x(deactivated)S 219 x(on)S 219 x(initia)S -2 x
(tor)S 220 x(request)S 219 x(when)S 220 x(a)S 3899 X 647 y(context)S
191 x(is)S 190 x(establis)S -2 x(hed.)S 268 x(The)S 191 x(initia)S -2 x
(tor)S 191 x(and)S 190 x(target)S 191 x(are)S 191 x(provided)S 190 x
(with)S 190 x(corresponding)S 190 x(indi)S -2 x(cators)S 3899 X 648 y
(\(replay_det_state)S 250 x(and)S 251 x(sequen)S -2 x(ce_state\),)S
270 x(signifying)S 250 x(whether)S 252 x(these)S 251 x(features)S 251 x
(are)S 251 x(active)S 252 x(on)S 251 x(a)S 3899 X 647 y(given)S 182 x
(context.)S 3899 14125 XY(An)S 160 x(example)S 160 x(mech_type)S 161 x
(supp)S -2 x(orting)S 161 x(replay)S 160 x(detection)S 160 x(might)S
161 x(\(when)S 161 x(replay_det_state)S 160 x(is)S 160 x(TRUE\))S 3899 X
647 y(implement)S 268 x(the)S 270 x(feature)S 270 x(as)S 269 x(follows:)S
418 x(The)S 269 x(underlying)S 269 x(mechanism)S 269 x(would)S 269 x
(insert)S 269 x(timestamps)S 3899 X 648 y(in)S 212 x(data)S 213 x(elements)S
212 x(output)S 212 x(by)S 213 x(Sign)S(\()S 84 x(\))S 213 x(and)S 213 x
(Seal)S(\()S 82 x(\))S(,)S 222 x(and)S 212 x(would)S 212 x(maintain)S
212 x(\(within)S 213 x(a)S 213 x(time-limited)S 3899 X 647 y(window\))S
156 x(a)S 155 x(cache)S 156 x(identifying)S 155 x(received)S 156 x(data)S
155 x(elements)S 155 x(processed)S 155 x(by)S 156 x(V)S -51 x(erify)S
(\()S 84 x(\))S 156 x(and)S 155 x(Unseal)S(\()S 82 x(\))S(.)S 236 x
(\(An)S 3899 X 648 y(impli)S -2 x(cit)S 258 x(tradeoff)S 259 x(exists)S
258 x(between)S 257 x(timestamp)S 258 x(resolution)S 257 x(and)S 257 x
(possi)S -2 x(ble)S 257 x(resulting)S 258 x(cache)S 258 x(size.\))S
3899 X 648 y(When)S 146 x(this)S 147 x(feature)S 147 x(is)S 147 x(active,)S
155 x(exception)S 147 x(status)S 146 x(returns)S 147 x(\(DUPL)S 2 x
(ICA)S -31 x(TE_TOKEN,)S 148 x(OLD_TOK)S 2 x(EN\))S 3899 X 647 y(will)S
215 x(be)S 215 x(provided)S 215 x(when)S 215 x(V)S -50 x(erify)S(\()S
84 x(\))S 216 x(or)S 216 x(Unseal)S -2 x(\()S 84 x(\))S 216 x(is)S 215 x
(presented)S 215 x(with)S 216 x(a)S 215 x(message)S 215 x(which)S 216 x
(is)S 215 x(either)S 216 x(a)S 3899 X 648 y(detected)S 258 x(dupli)S
- -2 x(cate)S 260 x(of)S 259 x(a)S 259 x(prior)S 258 x(message)S 259 x
(or)S 259 x(which)S 259 x(is)S 258 x(too)S 259 x(old)S 258 x(to)S 259 x
(valida)S -2 x(te)S 260 x(agains)S -2 x(t)S 259 x(a)S 259 x(cache)S
259 x(of)S 3899 X 647 y(recently)S 183 x(received)S 182 x(messages.)S
3899 20302 XY(When)S 145 x(sequence_sta)S -2 x(te)S 146 x(is)S 146 x
(TRUE,)S 145 x(V)S -51 x(erify)S(\()S 84 x(\))S 147 x(and)S 144 x(Unseal)S
(\()S 82 x(\))S 146 x(will)S 145 x(return)S 146 x(exception)S 146 x
(status)S 145 x(\(UNSEQ_)S 3899 X 647 y(TOKEN\))S 191 x(when)S 189 x
(presented)S 189 x(with)S 190 x(a)S 190 x(message)S 189 x(which)S 190 x
(is)S 189 x(earlier)S 190 x(in)S 189 x(an)S 189 x(ordered)S 190 x(message)S
189 x(sequence)S 3899 X 648 y(than)S 193 x(a)S 194 x(message)S 193 x
(previously)S 193 x(processed)S 193 x(on)S 194 x(the)S 193 x(context.)S
279 x(Message)S 193 x(sequencing)S 193 x(mechanisms)S 193 x(are)S 3899 X
647 y(speci\211c)S 182 x(to)S 182 x(underlying)S 182 x(mech_types.)S
3899 23739 XY F32(1.6)S 547 x(Credentials)S 3899 24735 XY F147(Credentia)S
- -2 x(ls)S 126 x(structures)S 127 x(provide)S 125 x(the)S 126 x(prerequisites)S
125 x(enabl)S -2 x(ing)S 126 x(peers)S 126 x(to)S 127 x(establ)S -2 x
(ish)S 126 x(security)S 126 x(contexts)S 3899 X 647 y(with)S 258 x(each)S
257 x(other)S -40 x(.)S 470 x(A)S 258 x(singl)S -2 x(e)S 258 x(credentials)S
257 x(structure)S 258 x(can)S 258 x(accomodate)S 258 x(credentials)S
256 x(for)S 259 x(multipl)S -2 x(e)S 3899 X 648 y(mech_types.)S 464 x
(Means)S 256 x(for)S 257 x(selection)S 255 x(of)S 257 x(option)S 255 x
(values)S 255 x(which)S 256 x(are)S 256 x(bound)S 255 x(into)S 256 x
(credentials)S 254 x(and)S 3899 X 648 y(which)S 153 x(are)S 152 x(speci\211c)S
152 x(to)S 153 x(particular)S 152 x(mech_types)S 153 x(\(e.g.,)S 160 x
(certain)S 153 x(Kerberos)S 153 x(V5)S 152 x(TGT)S 154 x(options\))S
153 x(are)S 152 x(local)S 3899 X 647 y(matters,)S 230 x(and)S 219 x
(will)S 219 x(likel)S -2 x(y)S 221 x(be)S 219 x(based)S 219 x(on)S 220 x
(selectively)S 219 x(user)S -10 x(-overridable)S 219 x(defaults)S 219 x
(establi)S -2 x(shed)S 219 x(as)S 220 x(a)S 3899 X 648 y(system)S 182 x
(management)S 183 x(function.)S 3899 28969 XY(A)S 260 x(generic)S 262 x
(credential)S 260 x(establ)S -2 x(ishment)S 261 x(call)S 260 x(is)S
260 x(de\211ned)S 260 x(within)S 260 x(the)S 261 x(API)S 261 x(in)S
261 x(supp)S -2 x(ort)S 262 x(of)S 261 x(appl)S -2 x(ica-)S 3899 X 648 y
(tion)S 177 x(portabil)S -2 x(ity)S -60 x(,)S 178 x(particularly)S 177 x
(oriented)S 177 x(to)S 177 x(support)S 177 x(of)S 178 x(portable)S 176 x
(server)S 178 x(appl)S -2 x(ications.)S 241 x(OS-speci\211c)S 3899 X
647 y(means)S 151 x(to)S 151 x(acquire)S 151 x(credentials)S 150 x(for)S
152 x(use)S 151 x(with)S 151 x(the)S 151 x(API)S 152 x(may)S 151 x(also)S
151 x(exist,)S 157 x(for)S 152 x(example)S 151 x(in)S 151 x(conjunction)S
3899 X 648 y(with)S 190 x(OS-speci\211c)S 191 x(login)S 190 x(functions)S
190 x(based)S 189 x(on)S 190 x(passwords)S 189 x(or)S 191 x(other)S
190 x(user)S 191 x(authenti)S -2 x(cation)S 190 x(technolo-)S 3899 X
647 y(gies.)S 3899 33054 XY F28(2)S 598 x(Interface)S 201 x(Descriptions)S
14368 37373 XY F36(28\203February\2031990:)S 221 x(DIGIT)S -36 x(AL)S
166 x(INTERNAL)S 166 x(USE)S 166 x(ONL)S -46 x(Y)S 498 x(3)S
%%EndCustomColor: 0
3 PP EP
%%PageTrailer
%%PageFonts: Helvetica-Bold NewCenturySchlbk-Roman
%%PageCustomColors: 0
%
%%Page: 4 4
%%BeginPageSetup
%%EndPageSetup
%%PageFonts: (atend)
%%PageCustomColors: (atend)
1000 BP PaperHeight PaperWidth PM 0 0 XY 
%%BeginCustomColor: 0 
0 SC 4048 2106 XY F40(Linn:)S 199 x(Generic)S 150 x(Security)S 151 x
(Service)S 150 x(API)S 3899 4013 XY F32(2.1)S 547 x(Credential)S 183 x
(manage)S -2 x(ment)S 183 x(calls)S 3899 5009 XY(2.1.1)S 547 x(Estab_cred)S
182 x(call)S 3899 X 897 y F147(Inputs:)S 3899 X 896 y(\201)S 714 x(desiredn)S
- -2 x(ame)S 183 x(OCTET)S 183 x(STRING,)S 3899 X 897 y(\201)S 714 x(timedelta)S
181 x(INTEGER,\202in)S 182 x(minutes;)S 182 x(0)S 182 x(requests)S 182 x
(default)S 3899 X 896 y(\201)S 714 x(desired_mechs)S 181 x(SET)S 183 x
(OF)S 183 x(INTEGER\202empty)S 182 x(set)S 183 x(requests)S 182 x(system)S
182 x(default)S 3899 9691 XY(Outputs:)S 3899 X 897 y(\201)S 714 x(major_status)S
182 x(INTEGER,)S 3899 X 897 y(\201)S 714 x(minor_status)S 182 x(INTEGER,)S
3899 X 896 y(\201)S 714 x(output_cred_hand)S -2 x(le)S 182 x(OCTET)S
183 x(STRING)S 3899 13477 XY(Return)S 182 x(major_status)S 182 x(values:)S
3899 X 897 y(\201)S 714 x(COMPLETE)S 182 x(ind)S -2 x(icates)S 181 x
(that)S 180 x(credentials)S 179 x(were)S 182 x(successfully)S 180 x
(establ)S -2 x(ished,)S 180 x(for)S 182 x(the)S 180 x(requested)S 4945 X
647 y(duration)S 140 x(and)S 141 x(for)S 143 x(the)S 141 x(requested)S
141 x(mech_types,)S 150 x(and)S 141 x(that)S 141 x(those)S 142 x(credentials)S
140 x(can)S 142 x(be)S 141 x(referenced)S 4945 X 648 y(for)S 183 x(subsequen)S
- -2 x(t)S 183 x(use)S 182 x(with)S 183 x(the)S 182 x(handle)S 181 x(returned)S
183 x(in)S 182 x(output_cred_han)S -2 x(dle.)S 3899 X 897 y(\201)S 714 x
(BAD_TIME)S 185 x(indi)S -2 x(cates)S 185 x(that)S 185 x(the)S 184 x
(input)S 184 x(timedelta)S 184 x(value)S 184 x(speci\211ed)S 183 x(an)S
185 x(unacceptab)S -2 x(le)S 185 x(valid)S -2 x(ity)S 4945 X 647 y(period,)S
182 x(causing)S 182 x(the)S 182 x(credential)S 182 x(establ)S -2 x(ishment)S
182 x(operation)S 182 x(to)S 182 x(fail.)S 3899 X 897 y(\201)S 714 x
(BAD_MECH)S 200 x(indicates)S 199 x(that)S 201 x(an)S 200 x(unavail)S
- -2 x(able)S 200 x(mech_type)S 201 x(was)S 200 x(requested,)S 205 x(causing)S
200 x(the)S 200 x(cre-)S 4945 X 647 y(dential)S 181 x(establi)S -2 x
(shment)S 182 x(operation)S 182 x(to)S 183 x(fail.)S 3899 X 897 y(\201)S
714 x(F)S -40 x(AILURE)S 124 x(indi)S -2 x(cates)S 125 x(that)S 125 x
(credential)S 123 x(establis)S -2 x(hment)S 125 x(failed)S 124 x(for)S
126 x(other)S 125 x(reasons,)S 136 x(includ)S -2 x(ing)S 125 x(lack)S
4945 X 648 y(of)S 183 x(authorizati)S -2 x(on)S 183 x(to)S 183 x(establi)S
- -2 x(sh)S 183 x(and)S 181 x(use)S 183 x(credential)S -2 x(s)S 183 x
(associated)S 181 x(with)S 183 x(the)S 182 x(identity)S 182 x(named)S
182 x(in)S 4945 X 647 y(the)S 183 x(inp)S -2 x(ut)S 183 x(desiredn)S
- -2 x(ame)S 183 x(argument.)S 3899 22045 XY(Estab_cred)S 129 x(is)S 130 x
(used)S 130 x(to)S 131 x(establi)S -2 x(sh)S 130 x(credentials)S 130 x
(so)S 130 x(that)S 131 x(a)S 130 x(principa)S -2 x(l)S 130 x(can)S 131 x
(initia)S -2 x(te)S 131 x(and)S 130 x(accept)S 130 x(security)S 3899 X
648 y(contexts)S 209 x(under)S 208 x(the)S 209 x(identity)S 208 x(represented)S
208 x(by)S 209 x(the)S 208 x(desiredna)S -2 x(me)S 209 x(input)S 208 x
(argument.)S 323 x(On)S 209 x(success-)S 3899 X 647 y(ful)S 234 x(completion,)S
247 x(the)S 235 x(returned)S 234 x(output_cred_handl)S -2 x(e)S 235 x
(result)S 234 x(provides)S 234 x(a)S 234 x(handl)S -2 x(e)S 235 x(for)S
235 x(subsequen)S -2 x(t)S 3899 X 648 y(references)S 183 x(to)S 183 x
(the)S 183 x(establ)S -2 x(ished)S 182 x(credential)S -2 x(s.)S 3899 24984 XY
(The)S 150 x(caller)S 150 x(of)S 150 x(Estab_cred)S(\()S 83 x(\))S 150 x
(can)S 150 x(designa)S -2 x(te)S 151 x(the)S 150 x(length)S 149 x(of)S
151 x(time)S 150 x(for)S 151 x(which)S 149 x(establish)S -2 x(ed)S 150 x
(credentials)S 3899 X 648 y(are)S 208 x(to)S 209 x(be)S 208 x(valid)S
207 x(\(timedelta)S 208 x(argument\),)S 215 x(beginning)S 208 x(at)S
208 x(the)S 208 x(present,)S 215 x(or)S 209 x(can)S 208 x(request)S
208 x(credentials)S 3899 X 647 y(with)S 185 x(a)S 185 x(default)S 185 x
(valid)S -2 x(ity)S 186 x(interval.)S 251 x(The)S 186 x(caller)S 185 x
(can)S 185 x(explicitly)S 184 x(specify)S 185 x(a)S 185 x(set)S 186 x
(of)S 186 x(mech_types)S 185 x(which)S 3899 X 648 y(are)S 149 x(to)S
150 x(be)S 149 x(accomodated)S 149 x(in)S 149 x(the)S 150 x(returned)S
149 x(credentials)S 148 x(\(desired_mechs)S 149 x(argument\),)S 157 x
(or)S 150 x(can)S 149 x(request)S 3899 X 647 y(credentials)S 181 x(for)S
183 x(a)S 183 x(system-de\211ned)S 181 x(default)S 182 x(set)S 183 x
(of)S 183 x(mech_types.)S 3899 28571 XY(It)S 144 x(is)S 143 x(the)S
144 x(responsi)S -2 x(bility)S 143 x(of)S 144 x(underlying)S 143 x(mechanisms)S
142 x(and)S 143 x(OS)S 144 x(functions)S 144 x(to)S 143 x(ensure)S 144 x
(that)S 143 x(the)S 144 x(abil)S -2 x(ity)S 3899 X 647 y(to)S 159 x
(acquire)S 158 x(and)S 157 x(use)S 159 x(credential)S -2 x(s)S 159 x
(associa)S -2 x(ted)S 159 x(with)S 158 x(a)S 159 x(given)S 158 x(identity)S
158 x(is)S 158 x(constrained)S 157 x(to)S 159 x(appropria)S -2 x(te)S
3899 X 648 y(processes)S 194 x(within)S 194 x(a)S 195 x(system.)S 280 x
(An)S 195 x(example)S 194 x(local)S 194 x(poli)S -2 x(cy)S 196 x(would)S
194 x(be)S 195 x(one)S 194 x(in)S 195 x(which)S 194 x(any)S 195 x(credentials)S
3899 X 647 y(received)S 142 x(as)S 142 x(a)S 142 x(result)S 142 x(of)S
143 x(login)S 142 x(to)S 142 x(a)S 142 x(given)S 143 x(user)S 142 x
(account,)S 151 x(or)S 142 x(of)S 143 x(delegation)S 141 x(of)S 143 x
(rights)S 142 x(to)S 143 x(that)S 142 x(account,)S 3899 X 648 y(are)S
182 x(accessible)S 182 x(by)S 182 x(processes)S 182 x(running)S 182 x
(under)S 182 x(that)S 182 x(account.)S 3899 32157 XY(Credentia)S -2 x
(l)S 128 x(establ)S -2 x(ishment)S 127 x(for)S 128 x(users)S 127 x(is)S
127 x(likely)S 127 x(to)S 127 x(require)S 127 x(access)S 127 x(to)S
128 x(passwords)S 126 x(or)S 128 x(other)S 127 x(quantities)S 3899 X
648 y(which)S 212 x(should)S 210 x(be)S 212 x(protected)S 212 x(locally)S
211 x(and)S 211 x(exposed)S 211 x(for)S 213 x(the)S 212 x(shortest)S
212 x(time)S 212 x(poss)S -2 x(ible.)S 331 x(As)S 212 x(a)S 212 x(result,)S
3899 X 647 y(it)S 189 x(may)S 189 x(often)S 189 x(be)S 189 x(app)S -2 x
(ropriate)S 189 x(for)S 189 x(preliminary)S 188 x(credential)S 188 x
(acquisi)S -2 x(tion)S 189 x(to)S 189 x(be)S 188 x(performed)S 189 x
(through)S 3899 X 648 y(local)S 163 x(means)S 163 x(in)S 163 x(conjunction)S
164 x(with)S 164 x(login,)S 167 x(with)S 164 x(resulting)S 163 x(prelimi)S
- -2 x(nary)S 164 x(credentials)S 163 x(set)S 163 x(aside)S 163 x(to)S
164 x(be)S 3899 X 647 y(referenced)S 167 x(by)S 166 x(a)S 166 x(subsequ)S
- -2 x(ent)S 167 x(call)S 165 x(to)S 167 x(Estab)S -2 x(_cred)S(\()S 84 x
(\))S(,)S 170 x(or)S 167 x(for)S 167 x(local)S 165 x(alternative)S 166 x
(means)S 166 x(to)S 166 x(be)S 166 x(used)S 165 x(to)S 3899 X 648 y
(establi)S -2 x(sh)S 182 x(credentials)S 182 x(for)S 183 x(a)S 182 x
(user)S 183 x(at)S 182 x(login)S 182 x(time.)S 3899 37373 XY F36(4)S
498 x(28\203February\2031990:)S 221 x(DIGIT)S -36 x(AL)S 166 x(INTERNAL)S
166 x(USE)S 166 x(ONL)S -46 x(Y)S
%%EndCustomColor: 0
4 PP EP
%%PageTrailer
%%PageFonts: Helvetica-Bold NewCenturySchlbk-Roman
%%PageCustomColors: 0
%
%%Page: 5 5
%%BeginPageSetup
%%EndPageSetup
%%PageFonts: (atend)
%%PageCustomColors: (atend)
1000 BP PaperHeight PaperWidth PM 0 0 XY 
%%BeginCustomColor: 0 
0 SC 19687 2106 XY F40(Linn:)S 199 x(Generic)S 150 x(Security)S 151 x
(Service)S 150 x(API)S 3899 3996 XY F32(2.1.2)S 547 x(Delete_cred)S
181 x(call)S 3899 X 896 y F147(Input:)S 3899 X 897 y(\201)S 714 x(cred_handl)S
- -2 x(e)S 183 x(OCTET)S 183 x(STRING)S 3899 6885 XY(Outputs:)S 3899 X
896 y(\201)S 714 x(major_status)S 182 x(INTEGER,)S 3899 X 897 y(\201)S
714 x(minor_status)S 182 x(INTEGER)S 3899 9774 XY(Return)S 182 x(major_status)S
182 x(values:)S 3899 X 897 y(\201)S 714 x(COMPLETE)S 233 x(ind)S -2 x
(icates)S 232 x(that)S 231 x(the)S 232 x(credentials)S 230 x(referenced)S
233 x(by)S 231 x(the)S 232 x(input)S 231 x(cred_handl)S -2 x(e)S 232 x
(were)S 4945 X 647 y(deleted)S 215 x(for)S 217 x(purpos)S -2 x(es)S
216 x(of)S 217 x(subseq)S -2 x(uent)S 216 x(access)S 216 x(by)S 216 x
(the)S 216 x(caller)S -41 x(.)S 344 x(The)S 217 x(effect)S 217 x(on)S
216 x(other)S 216 x(processes)S 4945 X 648 y(which)S 182 x(may)S 183 x
(be)S 182 x(authorized)S 181 x(shared)S 182 x(access)S 182 x(to)S 183 x
(such)S 182 x(credentials)S 181 x(is)S 182 x(a)S 183 x(local)S 181 x
(matter)S -40 x(.)S 3899 X 896 y(\201)S 714 x(NO_CRED)S 151 x(indi)S
- -2 x(cates)S 152 x(that)S 152 x(no)S 151 x(deletion)S 151 x(operation)S
151 x(was)S 151 x(performed,)S 159 x(either)S 152 x(because)S 151 x
(the)S 152 x(inpu)S -2 x(t)S 4945 X 648 y(cred_handl)S -2 x(e)S 223 x
(was)S 222 x(invalid)S 221 x(or)S 223 x(because)S 222 x(the)S 223 x
(caller)S 222 x(lacks)S 222 x(authoriz)S -2 x(ation)S 222 x(to)S 223 x
(access)S 222 x(the)S 223 x(refer-)S 4945 X 648 y(enced)S 182 x(credentials.)S
3899 15253 XY(Provides)S 152 x(a)S 152 x(means)S 152 x(for)S 153 x(a)S
152 x(caller)S 152 x(to)S 153 x(explicitl)S -2 x(y)S 153 x(request)S
152 x(that)S 152 x(credentials)S 151 x(be)S 152 x(deleted)S 151 x(when)S
153 x(their)S 152 x(use)S 3899 X 648 y(is)S 198 x(no)S 198 x(longer)S
199 x(required.)S 290 x(Note)S 199 x(that)S 198 x(system-speci\211c)S
198 x(credential)S 198 x(management)S 198 x(functions)S 198 x(are)S
199 x(als)S -2 x(o)S 3899 X 648 y(likely)S 188 x(to)S 189 x(exist,)S
191 x(for)S 190 x(example)S 188 x(to)S 189 x(assure)S 188 x(that)S 189 x
(credentials)S 188 x(shared)S 188 x(among)S 189 x(processes)S 188 x
(are)S 189 x(properly)S 3899 X 647 y(deleted)S 137 x(when)S 139 x(all)S
137 x(affected)S 139 x(processes)S 138 x(terminate,)S 147 x(even)S 139 x
(if)S 139 x(no)S 138 x(explicit)S 138 x(deleti)S -2 x(on)S 139 x(requests)S
138 x(are)S 138 x(issued)S 3899 X 648 y(by)S 182 x(those)S 183 x(processes.)S
3899 19338 XY F32(2.2)S 547 x(Context-level)S 183 x(calls)S 3899 20334 XY
(2.2.1)S 547 x(Init_sec_context)S 182 x(call)S 3899 X 897 y F147(Inputs:)S
3899 X 897 y(\201)S 714 x(claimant_cred_ha)S -2 x(ndle)S 182 x(OCTET)S
183 x(STRING,)S 183 x(\202NULL)S 183 x(speci\211es)S 181 x("use)S 182 x
(default")S 3899 X 896 y(\201)S 714 x(input_context_hand)S -2 x(le)S
182 x(INTEGER,)S 183 x(\2020)S 182 x(speci\211es)S 181 x("none)S 182 x
(assigned)S 181 x(yet")S 3899 X 897 y(\201)S 714 x(targname)S 182 x
(OCTET)S 184 x(STRING,)S 3899 X 897 y(\201)S 714 x(mech_type)S 183 x
(INTEGER,)S 182 x(\2020)S 182 x(speci\211es)S 181 x("use)S 183 x(default")S
3899 X 896 y(\201)S 714 x(deleg_req_\212ag)S 181 x(BOOLEAN,)S 3899 X
897 y(\201)S 714 x(mutual_req_\212a)S -2 x(g)S 183 x(BOOLEAN,)S 3899 X
896 y(\201)S 714 x(replay_det_req_\212a)S -2 x(g)S 183 x(BOOLEAN,)S
3899 X 897 y(\201)S 714 x(sequence_req_\212a)S -2 x(g)S 183 x(BOOLEAN,)S
3899 X 897 y(\201)S 714 x(chan_bind)S -2 x(ings)S 182 x(OCTET)S 183 x
(STRING,)S 3899 X 896 y(\201)S 714 x(input_token)S 181 x(OCTET)S 183 x
(STRING)S 3899 31293 XY(Outputs:)S 3899 X 897 y(\201)S 714 x(major_status)S
182 x(INTEGER,)S 3899 X 897 y(\201)S 714 x(minor_status)S 182 x(INTEGER,)S
3899 X 896 y(\201)S 714 x(output_context_handl)S -2 x(e)S 183 x(INTEGER,)S
3899 X 897 y(\201)S 714 x(output_token)S 182 x(OCTET)S 183 x(STRING,)S
3899 X 896 y(\201)S 714 x(deleg_state)S 182 x(BOOLEAN,)S 14368 37373 XY
F36(28\203February\2031990:)S 221 x(DIGIT)S -36 x(AL)S 166 x(INTERNAL)S
166 x(USE)S 166 x(ONL)S -46 x(Y)S 498 x(5)S
%%EndCustomColor: 0
5 PP EP
%%PageTrailer
%%PageFonts: Helvetica-Bold NewCenturySchlbk-Roman
%%PageCustomColors: 0
%
%%Page: 6 6
%%BeginPageSetup
%%EndPageSetup
%%PageFonts: (atend)
%%PageCustomColors: (atend)
1000 BP PaperHeight PaperWidth PM 0 0 XY 
%%BeginCustomColor: 0 
0 SC 4048 2106 XY F40(Linn:)S 199 x(Generic)S 150 x(Security)S 151 x
(Service)S 150 x(API)S 3899 4006 XY F147(\201)S 714 x(mutual_state)S
181 x(BOOLEAN,)S 3899 X 897 y(\201)S 714 x(replay_det_sta)S -2 x(te)S
183 x(BOOLEAN,)S 3899 X 897 y(\201)S 714 x(sequence_state)S 181 x(BOOLEAN)S
3899 6895 XY(Return)S 182 x(major_status)S 182 x(values:)S 3899 X 897 y
(\201)S 714 x(COMPLETE)S 226 x(ind)S -2 x(icates)S 225 x(that)S 224 x
(context-level)S 225 x(information)S 225 x(was)S 224 x(successfully)S
224 x(initial)S -2 x(ized,)S 234 x(and)S 4945 X 648 y(that)S 169 x(the)S
170 x(returned)S 169 x(output_token)S 169 x(will)S 168 x(provide)S 169 x
(suf\211cient)S 169 x(information)S 169 x(for)S 170 x(the)S 170 x(target)S
170 x(to)S 169 x(per-)S 4945 X 647 y(form)S 183 x(per)S -10 x(-message)S
183 x(processing)S 182 x(on)S 182 x(the)S 183 x(newly-establi)S -2 x
(shed)S 182 x(context.)S 3899 X 897 y(\201)S 714 x(DEFECTIVE_TOKEN)S
194 x(indicates)S 193 x(that)S 194 x(consistency)S 195 x(checks)S 194 x
(performed)S 195 x(on)S 194 x(the)S 195 x(input_token)S 4945 X 647 y
(failed,)S 182 x(preventing)S 182 x(further)S 183 x(processing)S 182 x
(from)S 184 x(being)S 182 x(performed)S 182 x(based)S 181 x(on)S 183 x
(that)S 182 x(token.)S 3899 X 897 y(\201)S 714 x(RETR)S -21 x(Y_NEEDE)S
- -2 x(D)S 141 x(indi)S -2 x(cates)S 140 x(that)S 140 x(control)S 141 x
(information)S 139 x(in)S 140 x(the)S 140 x(returned)S 140 x(output_token)S
140 x(must)S 4945 X 648 y(be)S 269 x(sent)S 269 x(to)S 270 x(the)S 270 x
(target,)S 292 x(and)S 268 x(that)S 270 x(a)S 269 x(reply)S 269 x(must)S
269 x(be)S 270 x(received)S 269 x(and)S 269 x(pas)S -2 x(sed)S 269 x
(as)S 269 x(the)S 270 x(inpu)S -2 x(t_)S 4945 X 647 y(token)S 201 x
(argument)S 201 x(to)S 201 x(another)S 200 x(call)S 200 x(to)S 201 x
(Init_sec_context,)S 206 x(before)S 201 x(per)S -10 x(-message)S 201 x
(processing)S 200 x(can)S 4945 X 648 y(be)S 182 x(performed)S 183 x
(in)S 182 x(conjunction)S 182 x(with)S 183 x(this)S 182 x(context.)S
3899 X 896 y(\201)S 714 x(CREDEN)S -2 x(TIALS_EXPIRED)S 233 x(indicates)S
231 x(that)S 232 x(the)S 233 x(credentials)S 231 x(provided)S 231 x
(through)S 233 x(the)S 233 x(inpu)S -2 x(t)S 4945 X 648 y(claimant_cred_ha)S
- -2 x(ndle)S 229 x(argument)S 230 x(are)S 230 x(no)S 230 x(longer)S 230 x
(valid,)S 241 x(so)S 230 x(context)S 231 x(establi)S -2 x(shment)S 230 x
(cannot)S 4945 X 648 y(be)S 182 x(completed.)S 3899 X 896 y(\201)S 714 x
(BAD_BINDINGS)S 163 x(indi)S -2 x(cates)S 164 x(that)S 164 x(a)S 163 x
(mismatch)S 164 x(between)S 164 x(the)S 163 x(caller)S -10 x(-provided)S
163 x(chan_bind)S -2 x(ings)S 4945 X 648 y(and)S 211 x(those)S 211 x
(extracted)S 212 x(from)S 213 x(the)S 211 x(input_token)S 211 x(was)S
211 x(detected,)S 219 x(signifying)S 211 x(a)S 211 x(security-relevant)S
4945 X 647 y(event)S 190 x(and)S 189 x(preventing)S 189 x(context)S
191 x(establi)S -2 x(shment.)S 265 x(\(This)S 190 x(result)S 190 x(will)S
189 x(be)S 189 x(returned)S 190 x(by)S 190 x(Init_sec_)S 4945 X 648 y
(context)S 183 x(only)S 182 x(for)S 184 x(contexts)S 183 x(where)S 183 x
(mutual_sta)S -2 x(te)S 183 x(is)S 182 x(TRUE.\))S 3899 X 897 y(\201)S
714 x(F)S -40 x(AILURE)S 148 x(indicates)S 148 x(that)S 149 x(context)S
150 x(setup)S 149 x(could)S 148 x(not)S 150 x(be)S 149 x(accomplis)S
- -2 x(hed,)S 156 x(and)S 148 x(that)S 150 x(no)S 149 x(interface-)S 4945 X
647 y(de\211ned)S 181 x(recovery)S 184 x(action)S 182 x(is)S 182 x(availab)S
- -2 x(le.)S 3899 21142 XY(Used)S 208 x(by)S 208 x(context)S 210 x(initia)S
- -2 x(tor)S -40 x(,)S 216 x(providin)S -2 x(g)S 210 x(an)S 208 x(output_token)S
208 x(suitabl)S -2 x(e)S 209 x(for)S 210 x(use)S 208 x(by)S 209 x(the)S
209 x(target)S 209 x(within)S 3899 X 648 y(the)S 182 x(selected)S 182 x
(mech_type')S -20 x(s)S 182 x(protocol.)S 3899 22786 XY(Using)S 177 x
(information)S 178 x(in)S 179 x(the)S 178 x(credentials)S 177 x(structure)S
179 x(referenced)S 179 x(by)S 179 x(claimant_cred_ha)S -2 x(ndle,)S
179 x(initia)S -2 x(l-)S 3899 X 647 y(ize)S 196 x(the)S 197 x(data)S
196 x(structures)S 198 x(required)S 196 x(to)S 197 x(establi)S -2 x
(sh)S 197 x(a)S 197 x(security)S 197 x(context)S 198 x(with)S 196 x
(target)S 198 x(targname.)S 287 x(The)S 3899 X 648 y(input_context_hand)S
- -2 x(le)S 250 x(argument)S 250 x(is)S 249 x(0,)S 267 x(specifying)S
250 x("not)S 250 x(yet)S 250 x(assigned",)S 266 x(on)S 250 x(the)S 250 x
(\211rst)S 250 x(Init_sec_)S 3899 X 648 y(context)S(\()S 84 x(\))S 222 x
(call)S 220 x(relating)S 221 x(to)S 221 x(a)S 221 x(given)S 221 x(context.)S
360 x(That)S 222 x(call)S 220 x(returns)S 221 x(an)S 221 x(output_context_handl)S
- -2 x(e)S 222 x(for)S 3899 X 647 y(future)S 201 x(referenc)S 2 x(es)S
200 x(to)S 202 x(this)S 200 x(context.)S 300 x(When)S 200 x(retry)S
202 x(attempts)S 201 x(to)S 201 x(Init_sec_context)S(\()S 84 x(\))S
201 x(are)S 201 x(needed)S 200 x(to)S 3899 X 648 y(perform)S 242 x(context)S
242 x(establi)S -2 x(shment,)S 256 x(the)S 242 x(previousl)S -2 x(y-retur)S
2 x(ned)S 240 x(non-zero)S 242 x(hand)S -2 x(le)S 241 x(value)S 241 x
(is)S 241 x(entered)S 3899 X 647 y(into)S 152 x(the)S 153 x(inpu)S -2 x
(t_context_handle)S 152 x(argument)S 153 x(and)S 151 x(will)S 152 x
(be)S 152 x(echoed)S 153 x(in)S 152 x(the)S 152 x(returned)S 153 x(output_context_)S
3899 X 648 y(handl)S -2 x(e)S 183 x(argument.)S 3899 28315 XY(The)S
134 x(initia)S -2 x(tor)S 135 x(may)S 133 x(request)S 134 x(various)S
133 x(context-level)S 134 x(functions)S 133 x(through)S 134 x(input)S
133 x(\212ags:)S 219 x(the)S 133 x(deleg_req_)S 3899 X 648 y(\212ag)S
201 x(requests)S 201 x(delegation)S 201 x(of)S 202 x(access)S 201 x
(rights,)S 207 x(the)S 202 x(mutual_req_\212)S -2 x(ag)S 202 x(requests)S
201 x(mutual)S 201 x(authentica-)S 3899 X 647 y(tion,)S 168 x(the)S
165 x(replay_det_req_\212ag)S 164 x(requests)S 164 x(that)S 165 x(replay)S
164 x(detection)S 165 x(features)S 165 x(be)S 165 x(app)S -2 x(lied)S
164 x(to)S 165 x(messages)S 3899 X 648 y(transferred)S 172 x(on)S 171 x
(the)S 172 x(establ)S -2 x(ished)S 171 x(context,)S 175 x(and)S 170 x
(the)S 172 x(sequence_req_\212a)S -2 x(g)S 172 x(requests)S 171 x(that)S
172 x(sequenci)S -2 x(ng)S 3899 X 647 y(be)S 149 x(enforced.)S 233 x
(Not)S 149 x(all)S 149 x(of)S 150 x(these)S 149 x(features)S 150 x(will)S
148 x(be)S 149 x(availab)S -2 x(le)S 150 x(in)S 149 x(all)S 148 x(underlying)S
148 x(mech_types;)S 161 x(the)S 149 x(cor-)S 3899 X 648 y(respondi)S
- -2 x(ng)S 191 x(return)S 192 x(state)S 191 x(values)S 190 x(indi)S -2 x
(cate,)S 194 x(as)S 191 x(a)S 190 x(function)S 191 x(of)S 192 x(mech_type)S
191 x(processing)S 190 x(capabil)S -2 x(ities)S 3899 X 648 y(and)S 181 x
(initiator)S -11 x(-provided)S 182 x(input)S 182 x(\212ags,)S 182 x
(the)S 183 x(set)S 182 x(of)S 183 x(features)S 183 x(which)S 182 x(will)S
182 x(be)S 182 x(active)S 183 x(on)S 182 x(the)S 183 x(context.)S 3899 33197 XY
(If)S 205 x(the)S 205 x(mutual_req_state)S 204 x(is)S 204 x(TRUE,)S
204 x(this)S 205 x(fact)S 205 x(will)S 204 x(be)S 205 x(re\212ected)S
205 x(in)S 204 x(the)S 205 x(output_token.)S 310 x(A)S 204 x(call)S
204 x(to)S 3899 X 647 y(Accept_sec_context)S(\()S 84 x(\))S 173 x(at)S
173 x(the)S 172 x(target)S 174 x(in)S 172 x(conjunction)S 172 x(with)S
173 x(such)S 172 x(a)S 173 x(context)S 173 x(will)S 172 x(return)S 173 x
(a)S 172 x(token)S 173 x(in)S 3899 X 648 y(order)S 183 x(to)S 182 x
(achieve)S 183 x(mutual)S 181 x(authentication.)S 3899 37373 XY F36
(6)S 498 x(28\203February\2031990:)S 221 x(DIGIT)S -36 x(AL)S 166 x
(INTERNAL)S 166 x(USE)S 166 x(ONL)S -46 x(Y)S
%%EndCustomColor: 0
6 PP EP
%%PageTrailer
%%PageFonts: Helvetica-Bold NewCenturySchlbk-Roman
%%PageCustomColors: 0
%
%%Page: 7 7
%%BeginPageSetup
%%EndPageSetup
%%PageFonts: (atend)
%%PageCustomColors: (atend)
1000 BP PaperHeight PaperWidth PM 0 0 XY 
%%BeginCustomColor: 0 
0 SC 19687 2106 XY F40(Linn:)S 199 x(Generic)S 150 x(Security)S 151 x
(Service)S 150 x(API)S 3899 4006 XY F147(The)S 224 x(chan_bindi)S -2 x
(ngs)S 224 x(argument)S 225 x(is)S 223 x(used)S 224 x(by)S 224 x(the)S
224 x(caller)S 224 x(to)S 224 x(provide)S 224 x(information)S 224 x
(bind)S -2 x(ing)S 224 x(the)S 224 x(se-)S 3899 X 648 y(curity)S 181 x
(context)S 182 x(to)S 182 x(security-related)S 181 x(characteristics)S
180 x(\(e.g.)S 2 x(,)S 181 x(addresses)S -2 x(,)S 182 x(cryptographic)S
181 x(keys\))S 182 x(of)S 182 x(the)S 3899 X 647 y(underlyin)S -2 x
(g)S 252 x(communications)S 250 x(channel.)S 449 x(The)S 252 x(inp)S
- -2 x(ut_token)S 251 x(argument)S 252 x(contains)S 250 x(a)S 251 x(message)S
251 x(re-)S 3899 X 648 y(ceived)S 199 x(from)S 201 x(the)S 200 x(target,)S
205 x(and)S 199 x(is)S 199 x(signi\211cant)S 199 x(only)S 200 x(on)S
199 x(a)S 200 x(call)S 199 x(to)S 200 x(Init_sec_context)S(\()S 84 x
(\))S 200 x(which)S 200 x(follows)S 3899 X 648 y(a)S 182 x(previous)S
182 x(return)S 183 x(indi)S -2 x(cating)S 183 x(RETR)S -21 x(Y_NEE)S
- -2 x(DED)S 183 x(major_status.)S 3899 7593 XY(It)S 254 x(is)S 253 x
(the)S 254 x(caller)S 30 x(')S -21 x(s)S 254 x(responsib)S -2 x(ility)S
254 x(to)S 254 x(establi)S -2 x(sh)S 254 x(a)S 253 x(communications)S
253 x(path)S 253 x(to)S 255 x(the)S 254 x(target,)S 272 x(and)S 253 x
(to)S 3899 X 647 y(transmit)S 176 x(the)S 177 x(output_token)S 176 x
(to)S 177 x(the)S 177 x(target)S 178 x(over)S 177 x(that)S 177 x(path.)S
241 x(The)S 177 x(output_token)S 176 x(can,)S 178 x(however)S -40 x
(,)S 179 x(be)S 3899 X 648 y(transmitted)S 209 x(along)S 210 x(with)S
211 x(the)S 210 x(\211rst)S 210 x(appli)S -2 x(cation-provided)S 209 x
(input)S 210 x(message)S 210 x(signed)S 209 x(in)S 210 x(conjunction)S
3899 X 648 y(with)S 182 x(this)S 182 x(context.)S 3899 10930 XY F32
(2.2.2)S 547 x(Accept_se)S -2 x(c_context)S 182 x(call)S 3899 X 897 y
F147(Inputs:)S 3899 X 897 y(\201)S 714 x(acceptor_cred_handl)S -2 x
(e)S 183 x(OCTET)S 183 x(STRING,)S 3899 X 896 y(\201)S 714 x(input_context_hand)S
- -2 x(le)S 182 x(INTEGER,)S 183 x(\2020)S 182 x(speci\211es)S 181 x("not)S
183 x(yet)S 183 x(assi)S -2 x(gned")S 3899 X 897 y(\201)S 714 x(chan_bind)S
- -2 x(ings)S 182 x(OCTET)S 183 x(STRING,)S 3899 X 897 y(\201)S 714 x
(input_token)S 181 x(OCTET)S 183 x(STRING)S 3899 16509 XY(Outputs:)S
3899 X 897 y(\201)S 714 x(major_status)S 182 x(INTEGER,)S 3899 X 897 y
(\201)S 714 x(minor_status)S 182 x(INTEGER,)S 3899 X 896 y(\201)S 714 x
(srcname)S 182 x(OCTET)S 184 x(STRING,)S 3899 X 897 y(\201)S 714 x(mech_type)S
183 x(INTEGER,)S 3899 X 897 y(\201)S 714 x(output_context_handl)S -2 x
(e)S 183 x(INTEGER,)S 3899 X 896 y(\201)S 714 x(deleg_state)S 182 x
(BOOLEAN,)S 3899 X 897 y(\201)S 714 x(mutual_state)S 181 x(BOOLEAN,)S
3899 X 897 y(\201)S 714 x(replay_det_sta)S -2 x(te)S 183 x(BOOLEAN,)S
3899 X 896 y(\201)S 714 x(sequence_state)S 181 x(BOOLEAN,)S 3899 X 897 y
(\201)S 714 x(delegated_cred_h)S -2 x(andle)S 182 x(OCTET)S 183 x(STRING,)S
3899 X 896 y(\201)S 714 x(output_token)S 182 x(OCTET)S 183 x(STRING)S
3899 27468 XY(Return)S 182 x(major_status)S 182 x(values:)S 3899 X 897 y
(\201)S 714 x(COMPLETE)S 223 x(indicates)S 221 x(that)S 222 x(context-level)S
223 x(data)S 221 x(structures)S 223 x(were)S 223 x(successfully)S 221 x
(initial)S -2 x(ized,)S 4945 X 648 y(and)S 148 x(that)S 149 x(per)S
- -10 x(-message)S 149 x(processing)S 148 x(can)S 149 x(now)S 149 x(be)S
149 x(performed)S 150 x(in)S 148 x(conjunction)S 149 x(with)S 149 x
(this)S 149 x(context.)S 3899 X 896 y(\201)S 714 x(DEFECTIVE_TOKEN)S
194 x(indicates)S 193 x(that)S 194 x(consistency)S 195 x(checks)S 194 x
(performed)S 195 x(on)S 194 x(the)S 195 x(input_token)S 4945 X 648 y
(failed,)S 182 x(preventing)S 182 x(further)S 183 x(processing)S 182 x
(from)S 184 x(being)S 182 x(performed)S 182 x(based)S 181 x(on)S 183 x
(that)S 182 x(token.)S 3899 X 896 y(\201)S 714 x(RETR)S -21 x(Y_NEEDE)S
- -2 x(D)S 141 x(indi)S -2 x(cates)S 140 x(that)S 140 x(control)S 141 x
(information)S 139 x(in)S 140 x(the)S 140 x(returned)S 140 x(output_token)S
140 x(must)S 4945 X 648 y(be)S 180 x(sent)S 181 x(to)S 181 x(the)S 181 x
(initi)S -2 x(ator)S -40 x(,)S 181 x(and)S 180 x(that)S 181 x(a)S 180 x
(response)S 180 x(must)S 181 x(be)S 180 x(received)S 181 x(and)S 180 x
(pass)S -2 x(ed)S 181 x(as)S 180 x(the)S 181 x(inpu)S -2 x(t_)S 4945 X
648 y(token)S 238 x(argument)S 238 x(to)S 238 x(another)S 238 x(call)S
237 x(to)S 238 x(Accept_sec_context,)S 252 x(before)S 239 x(per)S -10 x
(-message)S 237 x(processing)S 4945 X 647 y(can)S 182 x(be)S 183 x(performed)S
182 x(in)S 182 x(conjunction)S 183 x(with)S 182 x(this)S 182 x(context.)S
3899 X 897 y(\201)S 714 x(BAD_SIG)S 232 x(indicates)S 231 x(that)S 233 x
(the)S 232 x(received)S 232 x(input_token)S 232 x(contains)S 231 x(an)S
232 x(incorrect)S 233 x(signature,)S 245 x(so)S 4945 X 647 y(context)S
183 x(setup)S 182 x(cannot)S 182 x(be)S 183 x(accomplis)S -2 x(hed.)S
- -369 x 37373 Y F36(28\203February\2031990:)S 221 x(DIGIT)S -36 x(AL)S
166 x(INTERNAL)S 166 x(USE)S 166 x(ONL)S -46 x(Y)S 498 x(7)S
%%EndCustomColor: 0
7 PP EP
%%PageTrailer
%%PageFonts: Helvetica-Bold NewCenturySchlbk-Roman
%%PageCustomColors: 0
%
%%Page: 8 8
%%BeginPageSetup
%%EndPageSetup
%%PageFonts: (atend)
%%PageCustomColors: (atend)
1000 BP PaperHeight PaperWidth PM 0 0 XY 
%%BeginCustomColor: 0 
0 SC 4048 2106 XY F40(Linn:)S 199 x(Generic)S 150 x(Security)S 151 x
(Service)S 150 x(API)S 3899 4006 XY F147(\201)S 714 x(DUPLICA)S -30 x
(TE_TOKEN)S 269 x(indi)S -2 x(cates)S 269 x(that)S 268 x(the)S 268 x
(signature)S 268 x(on)S 269 x(the)S 268 x(received)S 269 x(inp)S -2 x
(ut_token)S 269 x(was)S 4945 X 648 y(correct,)S 137 x(but)S 124 x(that)S
124 x(the)S 124 x(input_token)S 123 x(was)S 124 x(recognized)S 124 x
(as)S 123 x(a)S 124 x(dupl)S -2 x(icate)S 124 x(of)S 125 x(an)S 124 x
(inpu)S -2 x(t_token)S 125 x(alread)S -2 x(y)S 4945 X 647 y(processed.)S
243 x(No)S 182 x(new)S 183 x(context)S 183 x(is)S 182 x(establi)S -2 x
(shed.)S 3899 X 897 y(\201)S 714 x(OLD_TO)S 2 x(KEN)S 163 x(indicates)S
163 x(that)S 164 x(the)S 164 x(signature)S 163 x(on)S 164 x(the)S 164 x
(received)S 164 x(input_token)S 163 x(was)S 163 x(correc)S 2 x(t,)S
168 x(but)S 4945 X 648 y(that)S 134 x(the)S 133 x(input_token)S 133 x
(is)S 133 x(too)S 134 x(old)S 133 x(to)S 134 x(be)S 134 x(checked)S
133 x(for)S 135 x(dupl)S -2 x(ication)S 133 x(against)S 133 x(previously-processed)S
4945 X 647 y(input_tokens)S -2 x(.)S 244 x(No)S 182 x(new)S 183 x(context)S
183 x(is)S 182 x(establis)S -2 x(hed.)S 3899 X 897 y(\201)S 714 x(CREDEN)S
- -2 x(TIALS_EXPIRED)S 233 x(indicates)S 231 x(that)S 232 x(the)S 233 x
(credentials)S 231 x(provided)S 231 x(through)S 233 x(the)S 233 x(inpu)S
- -2 x(t)S 4945 X 647 y(acceptor_cred_handl)S -2 x(e)S 163 x(argument)S
162 x(are)S 162 x(no)S 162 x(longer)S 163 x(valid)S -2 x(,)S 167 x(so)S
162 x(context)S 163 x(establ)S -2 x(ishment)S 162 x(cannot)S 162 x(be)S
4945 X 648 y(completed.)S 3899 X 897 y(\201)S 714 x(BAD_BINDINGS)S 163 x
(indi)S -2 x(cates)S 164 x(that)S 164 x(a)S 163 x(mismatch)S 164 x(between)S
164 x(the)S 163 x(caller)S -10 x(-provided)S 163 x(chan_bind)S -2 x
(ings)S 4945 X 647 y(and)S 211 x(those)S 211 x(extracted)S 212 x(from)S
213 x(the)S 211 x(input_token)S 211 x(was)S 211 x(detected,)S 219 x
(signifying)S 211 x(a)S 211 x(security-relevant)S 4945 X 648 y(event)S
183 x(and)S 181 x(preventing)S 183 x(context)S 183 x(establi)S -2 x
(shment.)S 3899 X 896 y(\201)S 714 x(F)S -40 x(AILURE)S 148 x(indicates)S
148 x(that)S 149 x(context)S 150 x(setup)S 149 x(could)S 148 x(not)S
150 x(be)S 149 x(accomplis)S -2 x(hed,)S 156 x(and)S 148 x(that)S 150 x
(no)S 149 x(interface-)S 4945 X 648 y(de\211ned)S 181 x(recovery)S 184 x
(action)S 182 x(is)S 182 x(availab)S -2 x(le.)S 3899 14517 XY(Used)S
222 x(by)S 224 x(context)S 224 x(target.)S 367 x(Using)S 223 x(information)S
223 x(in)S 223 x(the)S 224 x(credential)S -2 x(s)S 224 x(structure)S
224 x(referenced)S 224 x(by)S 224 x(the)S 3899 X 647 y(input)S 154 x
(acceptor_cred_handle,)S 160 x(verify)S 157 x(the)S 156 x(incoming)S
155 x(inpu)S -2 x(t_token)S 156 x(and)S 155 x(\(assuming)S 155 x(success\))S
155 x(return)S 3899 X 648 y(the)S 176 x(authenticated)S 175 x(srcname)S
176 x(and)S 175 x(the)S 176 x(mech_type)S 176 x(used.)S 241 x(This)S
176 x(may)S 176 x(necessitate)S 175 x(recourse)S 177 x(\(within)S 3899 X
648 y(or)S 183 x(beneath)S 181 x(the)S 183 x(API\))S 183 x(to)S 183 x
(servers,)S 183 x(directories,)S 182 x(etc.)S 245 x(in)S 182 x(order)S
182 x(to)S 183 x(get)S 183 x(needed)S 182 x(cache)S 182 x(entries.)S
3899 17456 XY(The)S 176 x(input_context_hand)S -2 x(le)S 176 x(argument)S
176 x(is)S 175 x(0,)S 178 x(specifying)S 175 x("not)S 176 x(yet)S 177 x
(assi)S -2 x(gned",)S 178 x(on)S 176 x(the)S 176 x(\211rst)S 176 x(Accept_)S
3899 X 647 y(sec_context)S(\()S 84 x(\))S 138 x(call)S 138 x(relating)S
137 x(to)S 139 x(a)S 137 x(given)S 138 x(context.)S 230 x(That)S 138 x
(call)S 138 x(returns)S 138 x(an)S 137 x(output_context_handle)S 137 x
(for)S 3899 X 648 y(future)S 214 x(references)S 215 x(to)S 214 x(this)S
213 x(context;)S 231 x(when)S 214 x(retry)S 215 x(attempts)S 213 x(to)S
214 x(Accept_sec_context)S(\()S 84 x(\))S 215 x(are)S 214 x(needed)S
3899 X 648 y(to)S 167 x(perform)S 167 x(context)S 167 x(establi)S -2 x
(shment,)S 170 x(that)S 166 x(handle)S 165 x(value)S 166 x(will)S 166 x
(be)S 166 x(entered)S 166 x(into)S 167 x(the)S 166 x(input_context_)S
3899 X 647 y(handl)S -2 x(e)S 183 x(argument.)S 3899 21042 XY(The)S
224 x(chan_bindi)S -2 x(ngs)S 224 x(argument)S 225 x(is)S 223 x(used)S
224 x(by)S 224 x(the)S 224 x(caller)S 224 x(to)S 224 x(provide)S 224 x
(information)S 224 x(bind)S -2 x(ing)S 224 x(the)S 224 x(se-)S 3899 X
648 y(curity)S 181 x(context)S 182 x(to)S 182 x(security-related)S 181 x
(characteristics)S 180 x(\(e.g.)S 2 x(,)S 181 x(addresses)S -2 x(,)S
182 x(cryptographic)S 181 x(keys\))S 182 x(of)S 182 x(the)S 3899 X 648 y
(underlyin)S -2 x(g)S 183 x(communications)S 182 x(channel.)S 3899 23334 XY
(The)S 127 x(returned)S 127 x(state)S 126 x(results)S 126 x(\(deleg_state,)S
138 x(mutual_s)S -2 x(tate,)S 139 x(replay_d)S -2 x(et_state,)S 138 x
(and)S 126 x(sequence_state\))S 3899 X 647 y(re\212ect)S 140 x(the)S
140 x(same)S 140 x(context)S 140 x(state)S 140 x(values)S 139 x(as)S
139 x(returned)S 140 x(to)S 140 x(Init_sec_context)S(\()S 83 x(\))S
(')S -20 x(s)S 140 x(caller)S 139 x(at)S 140 x(the)S 140 x(initi)S -2 x
(ator)S 3899 X 648 y(system.)S 3899 25625 XY(The)S 126 x(delegated_cred_h)S
- -2 x(andle)S 125 x(result)S 125 x(is)S 125 x(signi\211cant)S 125 x(only)S
125 x(when)S 126 x(deleg_sta)S -2 x(te)S 126 x(is)S 125 x(TRUE,)S 126 x
(and)S 125 x(provides)S 3899 X 648 y(a)S 137 x(means)S 136 x(for)S 138 x
(the)S 137 x(target)S 137 x(to)S 137 x(reference)S 138 x(the)S 137 x
(delegated)S 136 x(credentials)S -2 x(.)S 229 x(The)S 137 x(output_token)S
137 x(result,)S 146 x(when)S 3899 X 647 y(non-NULL,)S 183 x(provides)S
181 x(a)S 183 x(control)S 182 x(message)S 182 x(to)S 183 x(be)S 183 x
(returned)S 182 x(to)S 183 x(the)S 182 x(initiator)S -41 x(.)S 3899 27917 XY
(Note:)S 373 x(A)S 248 x(target)S 248 x(must)S 247 x(be)S 247 x(able)S
247 x(to)S 248 x(dis)S -2 x(tinguish)S 247 x(a)S 247 x(context-level)S
248 x(input_token,)S 263 x(which)S 247 x(is)S 247 x(passed)S 3899 X
647 y(to)S 198 x(Accept_sec_context,)S 203 x(from)S 199 x(the)S 198 x
(per)S -10 x(-message)S 198 x(data)S 197 x(elements)S 197 x(passed)S
196 x(to)S 199 x(V)S -51 x(erify)S(\()S 84 x(\))S 198 x(or)S 199 x(Unseal)S
- -2 x(\()S 84 x(\))S(.)S 3899 X 648 y(These)S 230 x(data)S 228 x(elements)S
230 x(may)S 229 x(arrive)S 230 x(in)S 230 x(a)S 229 x(single)S 229 x
(appl)S -2 x(ication)S 229 x(message,)S 241 x(and)S 229 x(Accept_sec_context)S
3899 X 647 y(must)S 182 x(be)S 183 x(performed)S 182 x(before)S 183 x
(per)S -10 x(-message)S 183 x(processing)S 181 x(can)S 183 x(be)S 182 x
(performed)S 183 x(successfully)S -62 x(.)S 3899 31254 XY F32(2.2.3)S
547 x(Delete_sec)S -2 x(_context)S 182 x(call)S 3899 X 897 y F147(Input:)S
3899 X 896 y(\201)S 714 x(context_handle)S 181 x(INTEGER)S 3899 34143 XY
(Outputs:)S 3899 X 897 y(\201)S 714 x(major_status)S 182 x(INTEGER,)S
3899 37373 XY F36(8)S 498 x(28\203February\2031990:)S 221 x(DIGIT)S
- -36 x(AL)S 166 x(INTERNAL)S 166 x(USE)S 166 x(ONL)S -46 x(Y)S
%%EndCustomColor: 0
8 PP EP
%%PageTrailer
%%PageFonts: Helvetica-Bold NewCenturySchlbk-Roman
%%PageCustomColors: 0
%
%%Page: 9 9
%%BeginPageSetup
%%EndPageSetup
%%PageFonts: (atend)
%%PageCustomColors: (atend)
1000 BP PaperHeight PaperWidth PM 0 0 XY 
%%BeginCustomColor: 0 
0 SC 19687 2106 XY F40(Linn:)S 199 x(Generic)S 150 x(Security)S 151 x
(Service)S 150 x(API)S 3899 4006 XY F147(\201)S 714 x(minor_status)S
182 x(INTEGER,)S 3899 X 897 y(\201)S 714 x(output_token)S 182 x(OCTET)S
183 x(STRING)S 3899 5999 XY(This)S 165 x(call)S 164 x(can)S 165 x(be)S
165 x(made)S 164 x(by)S 165 x(either)S 165 x(member)S 166 x(of)S 165 x
(a)S 165 x(security)S 165 x(context,)S 170 x(to)S 165 x(\212ush)S 164 x
(context-)S 2 x(speci\211)S -2 x(c)S 166 x(infor-)S 3899 X 647 y(mation)S
187 x(and)S 187 x(to)S 188 x(return)S 189 x(an)S 187 x(output_token)S
187 x(which)S 188 x(can)S 188 x(be)S 188 x(pass)S -2 x(ed)S 188 x(to)S
188 x(the)S 188 x(context')S -20 x(s)S 188 x(peer)S 188 x(informing)S
3899 X 648 y(it)S 184 x(that)S 184 x(the)S 184 x(peer)S 30 x(')S -21 x
(s)S 184 x(corresponding)S 184 x(context)S 184 x(information)S 184 x
(can)S 184 x(also)S 183 x(be)S 184 x(\212ushed.)S 247 x(\(Once)S 185 x
(a)S 184 x(context)S 185 x(is)S 3899 X 648 y(establi)S -2 x(shed,)S
173 x(the)S 171 x(peers)S 170 x(involved)S 170 x(are)S 170 x(expected)S
171 x(to)S 171 x(retain)S 170 x(cached)S 171 x(credential)S 169 x(and)S
170 x(context-r)S 2 x(elated)S 3899 X 647 y(information)S 133 x(until)S
133 x(the)S 134 x(information')S -21 x(s)S 134 x(expiration)S 133 x
(time)S 133 x(is)S 134 x(reached)S 133 x(or)S 134 x(until)S 133 x(a)S
134 x(Delete_sec_context)S(\()S 84 x(\))S 3899 X 648 y(call)S 191 x
(is)S 191 x(made.\))S 271 x(Attempts)S 191 x(to)S 192 x(perform)S 192 x
(per)S -10 x(-message)S 192 x(processin)S -2 x(g)S 192 x(on)S 192 x
(a)S 191 x(deleted)S 191 x(context)S 192 x(will)S 191 x(result)S 3899 X
647 y(in)S 182 x(error)S 183 x(returns.)S 3899 11379 XY F32(2.3)S 547 x
(Per-message)S 182 x(calls)S 3899 12375 XY(2.3.1)S 547 x(Sign)S 183 x
(call)S 3899 X 897 y F147(Inputs:)S 3899 X 896 y(\201)S 714 x(context_handle)S
181 x(INTEGER,)S 3899 X 897 y(\201)S 714 x(message)S 182 x(OCTET)S 183 x
(STRING)S 3899 16161 XY(Outputs:)S 3899 X 896 y(\201)S 714 x(major_status)S
182 x(INTEGER,)S 3899 X 897 y(\201)S 714 x(minor_status)S 182 x(INTEGER,)S
3899 X 897 y(\201)S 714 x(per_msg_token)S 182 x(OCTET)S 183 x(STRING)S
3899 19947 XY(Return)S 182 x(major_status)S 182 x(values:)S 3899 X 896 y
(\201)S 714 x(COMPLETE)S 140 x(indicates)S 139 x(that)S 139 x(a)S 139 x
(signature,)S 148 x(suitabl)S -2 x(e)S 140 x(for)S 141 x(an)S 139 x
(establ)S -2 x(ished)S 139 x(security)S 140 x(context,)S 149 x(was)S
4945 X 648 y(successfully)S 178 x(appl)S -2 x(ied)S 178 x(and)S 178 x
(that)S 179 x(the)S 179 x(message)S 178 x(and)S 178 x(corresponding)S
178 x(per_msg_token)S 179 x(are)S 179 x(ready)S 4945 X 647 y(for)S 183 x
(transmission)S -2 x(.)S 3899 X 897 y(\201)S 714 x(CONTEXT_EXPIRED)S
228 x(indicates)S 227 x(that)S 229 x(context-related)S 229 x(data)S
228 x(items)S 229 x(have)S 228 x(expired,)S 240 x(so)S 229 x(that)S
4945 X 648 y(the)S 183 x(requested)S 181 x(operation)S 182 x(cannot)S
182 x(be)S 182 x(performed.)S 3899 X 896 y(\201)S 714 x(CREDEN)S -2 x
(TIALS_EXPIRED)S 173 x(indicates)S 171 x(that)S 172 x(the)S 173 x(context)S
173 x(is)S 172 x(recognized,)S 174 x(but)S 173 x(that)S 172 x(its)S
172 x(associ-)S 4945 X 648 y(ated)S 182 x(credentials)S 181 x(have)S
182 x(expired,)S 183 x(so)S 182 x(that)S 182 x(the)S 183 x(requested)S
181 x(operation)S 182 x(cannot)S 182 x(be)S 183 x(performed.)S 3899 X
896 y(\201)S 714 x(F)S -40 x(AILURE)S 252 x(indicates)S 252 x(that)S
253 x(the)S 253 x(context)S 254 x(is)S 252 x(recognized,)S 271 x(but)S
253 x(that)S 253 x(the)S 253 x(requested)S 253 x(operation)S 4945 X
648 y(could)S 182 x(not)S 182 x(be)S 183 x(performed)S 182 x(for)S 184 x
(reasons)S 181 x(identi\211ed)S 181 x(by)S 183 x(minor_status)S 181 x
(codes.)S 3899 X 897 y(\201)S 714 x(NO_CONTEXT)S 235 x(indicates)S 234 x
(that)S 235 x(no)S 236 x(valid)S 234 x(context)S 236 x(was)S 235 x(recognized)S
235 x(for)S 236 x(the)S 236 x(inp)S -2 x(ut)S 236 x(context_)S 4945 X
647 y(handl)S -2 x(e)S 183 x(provided.)S 3899 29411 XY(Using)S 251 x
(the)S 251 x(security)S 252 x(context)S 253 x(referenced)S 252 x(by)S
252 x(context_handle,)S 268 x(appl)S -2 x(y)S 252 x(a)S 252 x(signature)S
251 x(to)S 252 x(the)S 252 x(inpu)S -2 x(t)S 3899 X 648 y(message)S
144 x(\(along)S 144 x(with)S 144 x(timestamps)S 143 x(and/or)S 144 x
(other)S 144 x(data)S 144 x(includ)S -2 x(ed)S 144 x(in)S 144 x(supp)S
- -2 x(ort)S 145 x(of)S 145 x(mech_type-speci\211c)S 3899 X 647 y(mechanisms\))S
208 x(and)S 208 x(return)S 209 x(the)S 209 x(result)S 209 x(in)S 208 x
(per_msg_token.)S 323 x(The)S 209 x(caller)S 209 x(pass)S -2 x(es)S
209 x(the)S 209 x(message)S 208 x(and)S 3899 X 648 y(the)S 182 x(per_msg_token)S
183 x(to)S 182 x(the)S 183 x(target.)S 3899 32350 XY(The)S 213 x(Sign)S
(\()S 84 x(\))S 214 x(function)S 213 x(completes)S 212 x(before)S 214 x
(the)S 213 x(message)S 213 x(and)S 212 x(per_msg_token)S 213 x(is)S
213 x(sent)S 213 x(to)S 213 x(the)S 213 x(peer;)S 3899 X 648 y(successful)S
199 x(appl)S -2 x(ication)S 199 x(of)S 200 x(Sign)S(\()S 83 x(\))S 201 x
(does)S 198 x(not)S 200 x(guarantee)S 199 x(that)S 200 x(a)S 199 x(corresponding)S
199 x(V)S -51 x(erify)S(\()S 84 x(\))S 200 x(has)S 199 x(been)S 3899 X
647 y(\(or)S 172 x(can)S 171 x(necessaril)S -2 x(y)S 172 x(be\))S 171 x
(performed)S 172 x(successfully)S 170 x(when)S 171 x(the)S 171 x(message)S
171 x(arrives)S 171 x(at)S 171 x(the)S 171 x(destinati)S -2 x(on.)S
14368 37373 XY F36(28\203February\2031990:)S 221 x(DIGIT)S -36 x(AL)S
166 x(INTERNAL)S 166 x(USE)S 166 x(ONL)S -46 x(Y)S 498 x(9)S
%%EndCustomColor: 0
9 PP EP
%%PageTrailer
%%PageFonts: Helvetica-Bold NewCenturySchlbk-Roman
%%PageCustomColors: 0
%
%%Page: 10 10
%%BeginPageSetup
%%EndPageSetup
%%PageFonts: (atend)
%%PageCustomColors: (atend)
1000 BP PaperHeight PaperWidth PM 0 0 XY 
%%BeginCustomColor: 0 
0 SC 4048 2106 XY F40(Linn:)S 199 x(Generic)S 150 x(Security)S 151 x
(Service)S 150 x(API)S 3899 3996 XY F32(2.3.2)S 547 x(V)S -29 x(erify)S
183 x(call)S 3899 X 896 y F147(Inputs:)S 3899 X 897 y(\201)S 714 x(context_handle)S
181 x(INTEGER,)S 3899 X 897 y(\201)S 714 x(message)S 182 x(OCTET)S 183 x
(STRING,)S 3899 X 896 y(\201)S 714 x(per_msg_token)S 182 x(OCTET)S 183 x
(STRING)S 3899 8678 XY(Outputs:)S 3899 X 897 y(\201)S 714 x(major_status)S
182 x(INTEGER,)S 3899 X 896 y(\201)S 714 x(minor_status)S 182 x(INTEGER,)S
3899 11567 XY(Return)S 182 x(major_status)S 182 x(values:)S 3899 X 897 y
(\201)S 714 x(COMPLETE)S 183 x(indicates)S 181 x(that)S 183 x(the)S
182 x(message)S 182 x(was)S 183 x(successfully)S 181 x(veri\211ed.)S
3899 X 896 y(\201)S 714 x(DEFECTIVE_TOKEN)S 158 x(indi)S -2 x(cates)S
159 x(that)S 158 x(consistency)S 158 x(checks)S 158 x(performed)S 159 x
(on)S 158 x(the)S 158 x(received)S 159 x(per_)S 4945 X 648 y(msg_token)S
177 x(failed,)S 177 x(preventing)S 176 x(further)S 178 x(processing)S
176 x(from)S 178 x(being)S 176 x(performed)S 177 x(with)S 177 x(that)S
176 x(token.)S 3899 X 897 y(\201)S 714 x(BAD_SIG)S 155 x(indi)S -2 x
(cates)S 155 x(that)S 154 x(the)S 155 x(received)S 154 x(per_msg_token)S
155 x(contains)S 153 x(an)S 154 x(incorrect)S 156 x(signature)S 154 x
(for)S 4945 X 647 y(the)S 183 x(message.)S 3899 X 897 y(\201)S 714 x
(DUPLICA)S -30 x(TE_TOKEN)S 183 x(indicates)S 181 x(that)S 183 x(the)S
183 x(signature)S 182 x(on)S 183 x(the)S 182 x(received)S 183 x(per_msg_token)S
183 x(was)S 4945 X 647 y(correct)S 187 x(for)S 187 x(the)S 186 x(input)S
185 x(message,)S 187 x(but)S 186 x(that)S 185 x(\(through)S 187 x(means)S
185 x(speci\211c)S 186 x(to)S 186 x(mech_type\))S 187 x(the)S 186 x
(per_)S 4945 X 648 y(msg)S 157 x(token)S 156 x(was)S 156 x(recognized)S
156 x(as)S 156 x(a)S 156 x(dup)S -2 x(licate)S 156 x(of)S 157 x(a)S
156 x(previously-processed)S 155 x(per_msg_token.)S 235 x(This)S 4945 X
648 y(major_status)S 164 x(will)S 164 x(be)S 164 x(returned)S 164 x
(only)S 164 x(for)S 166 x(contexts)S 165 x(for)S 165 x(which)S 164 x
(replay_det_state)S 163 x(or)S 165 x(sequence_)S 4945 X 647 y(state)S
182 x(is)S 182 x(TRUE.)S 3899 X 897 y(\201)S 714 x(OLD_TO)S 2 x(KEN)S
188 x(indicates)S 188 x(that)S 189 x(the)S 188 x(signature)S 189 x(on)S
189 x(the)S 189 x(received)S 188 x(per_msg_token)S 189 x(was)S 189 x
(correct,)S 4945 X 647 y(but)S 218 x(that)S 218 x(the)S 219 x(token)S
218 x(is)S 218 x(too)S 219 x(old)S 217 x(to)S 219 x(be)S 218 x(checked)S
219 x(for)S 219 x(dupl)S -2 x(ication.)S 351 x(This)S 218 x(major_status)S
218 x(will)S 218 x(be)S 4945 X 648 y(returned)S 182 x(only)S 183 x(for)S
183 x(contexts)S 183 x(for)S 183 x(which)S 183 x(replay_de)S -2 x(t_state)S
183 x(or)S 183 x(sequence_sta)S -2 x(te)S 183 x(is)S 182 x(TRUE.)S 3899 X
897 y(\201)S 714 x(UNSEQ_TOKEN)S 199 x(indi)S -2 x(cates)S 199 x(that)S
199 x(the)S 199 x(signature)S 199 x(on)S 199 x(the)S 199 x(received)S
199 x(per_msg_token)S 199 x(was)S 198 x(cor-)S 4945 X 647 y(rect,)S
179 x(but)S 177 x(that)S 177 x(it)S 176 x(is)S 177 x(earlier)S 176 x
(in)S 177 x(a)S 176 x(sequenced)S 176 x(stream)S 177 x(than)S 176 x
(a)S 177 x(token)S 177 x(already)S 176 x(processed)S 176 x(on)S 177 x
(the)S 4945 X 648 y(context.)S 264 x(This)S 189 x(major_status)S 188 x
(will)S 189 x(be)S 189 x(returned)S 189 x(only)S 188 x(for)S 190 x(contexts)S
190 x(for)S 190 x(which)S 189 x(sequence_sta)S -2 x(te)S 4945 X 647 y
(is)S 182 x(TRUE.)S 3899 X 897 y(\201)S 714 x(CONTEXT_EXPIRED)S 228 x
(indicates)S 227 x(that)S 229 x(context-related)S 229 x(data)S 228 x
(items)S 229 x(have)S 228 x(expired,)S 240 x(so)S 229 x(that)S 4945 X
648 y(the)S 183 x(requested)S 181 x(operation)S 182 x(cannot)S 182 x
(be)S 182 x(performed.)S 3899 X 896 y(\201)S 714 x(CREDEN)S -2 x(TIALS_EXPIRED)S
173 x(indicates)S 171 x(that)S 172 x(the)S 173 x(context)S 173 x(is)S
172 x(recognized,)S 174 x(but)S 173 x(that)S 172 x(its)S 172 x(associ-)S
4945 X 648 y(ated)S 182 x(credentials)S 181 x(have)S 182 x(expired,)S
183 x(so)S 182 x(that)S 182 x(the)S 183 x(requested)S 181 x(operation)S
182 x(cannot)S 182 x(be)S 183 x(performed.)S 3899 X 896 y(\201)S 714 x
(F)S -40 x(AILURE)S 164 x(indicates)S 164 x(that)S 166 x(the)S 165 x
(context)S 167 x(is)S 165 x(recognized,)S 168 x(but)S 165 x(that)S 166 x
(the)S 165 x(V)S -50 x(erify)S(\()S 84 x(\))S 166 x(operation)S 164 x
(could)S 4945 X 648 y(not)S 183 x(be)S 182 x(performed)S 183 x(for)S
183 x(reasons)S 182 x(identi)S -2 x(\211ed)S 182 x(by)S 183 x(minor_status)S
181 x(codes.)S 3899 X 897 y(\201)S 714 x(NO_CONTEXT)S 235 x(indicates)S
234 x(that)S 235 x(no)S 236 x(valid)S 234 x(context)S 236 x(was)S 235 x
(recognized)S 235 x(for)S 236 x(the)S 236 x(inp)S -2 x(ut)S 236 x(context_)S
4945 X 647 y(handl)S -2 x(e)S 183 x(provided.)S 3899 31343 XY(Using)S
244 x(the)S 246 x(security)S 245 x(context)S 246 x(referenced)S 246 x
(by)S 245 x(context_handle,)S 261 x(verify)S 246 x(that)S 245 x(the)S
245 x(input)S 245 x(per_msg_)S 3899 X 648 y(token)S 164 x(contains)S
164 x(an)S 164 x(appropria)S -2 x(te)S 165 x(signature)S 164 x(for)S
165 x(the)S 165 x(input)S 163 x(message,)S 168 x(and)S 164 x(appl)S
- -2 x(y)S 165 x(any)S 165 x(active)S 164 x(replay)S 3899 X 647 y(detection)S
182 x(or)S 183 x(sequencin)S -2 x(g)S 183 x(features.)S 3899 37373 XY
F36(10)S 498 x(28\203February\2031990:)S 221 x(DIGIT)S -36 x(AL)S 166 x
(INTERNAL)S 166 x(USE)S 166 x(ONL)S -46 x(Y)S
%%EndCustomColor: 0
10 PP EP
%%PageTrailer
%%PageFonts: Helvetica-Bold NewCenturySchlbk-Roman
%%PageCustomColors: 0
%
%%Page: 11 11
%%BeginPageSetup
%%EndPageSetup
%%PageFonts: (atend)
%%PageCustomColors: (atend)
1000 BP PaperHeight PaperWidth PM 0 0 XY 
%%BeginCustomColor: 0 
0 SC 19687 2106 XY F40(Linn:)S 199 x(Generic)S 150 x(Security)S 151 x
(Service)S 150 x(API)S 3899 4013 XY F32(2.3.3)S 547 x(Seal)S 183 x(call)S
3899 X 896 y F147(Inputs:)S 3899 X 897 y(\201)S 714 x(context_handle)S
181 x(INTEGER,)S 3899 X 897 y(\201)S 714 x(conf_\212ag)S 183 x(BOOLEAN,)S
3899 X 896 y(\201)S 714 x(input_mess)S -2 x(age)S 183 x(OCTET)S 183 x
(STRING)S 3899 8695 XY(Outputs:)S 3899 X 897 y(\201)S 714 x(major_status)S
182 x(INTEGER,)S 3899 X 896 y(\201)S 714 x(minor_status)S 182 x(INTEGER,)S
3899 X 897 y(\201)S 714 x(output_messa)S -2 x(ge)S 183 x(OCTET)S 183 x
(STRING)S 3899 12481 XY(Return)S 182 x(major_status)S 182 x(values:)S
3899 X 896 y(\201)S 714 x(COMPLETE)S 181 x(indi)S -2 x(cates)S 180 x
(that)S 180 x(the)S 179 x(input_messa)S -2 x(ge)S 181 x(was)S 179 x
(successfully)S 179 x(processed)S 179 x(and)S 179 x(that)S 180 x(the)S
4945 X 648 y(output_messa)S -2 x(ge)S 183 x(is)S 182 x(ready)S 183 x
(for)S 183 x(transmissi)S -2 x(on.)S 3899 X 897 y(\201)S 714 x(CONTEXT_EXPIRED)S
228 x(indicates)S 227 x(that)S 229 x(context-related)S 229 x(data)S
228 x(items)S 229 x(have)S 228 x(expired,)S 240 x(so)S 229 x(that)S
4945 X 647 y(the)S 183 x(requested)S 181 x(operation)S 182 x(cannot)S
182 x(be)S 182 x(performed.)S 3899 X 897 y(\201)S 714 x(CREDEN)S -2 x
(TIALS_EXPIRED)S 173 x(indicates)S 171 x(that)S 172 x(the)S 173 x(context)S
173 x(is)S 172 x(recognized,)S 174 x(but)S 173 x(that)S 172 x(its)S
172 x(associ-)S 4945 X 647 y(ated)S 182 x(credentials)S 181 x(have)S
182 x(expired,)S 183 x(so)S 182 x(that)S 182 x(the)S 183 x(requested)S
181 x(operation)S 182 x(cannot)S 182 x(be)S 183 x(performed.)S 3899 X
897 y(\201)S 714 x(F)S -40 x(AILURE)S 199 x(indi)S -2 x(cates)S 200 x
(that)S 200 x(the)S 200 x(context)S 201 x(is)S 200 x(recognized,)S 204 x
(but)S 200 x(that)S 200 x(the)S 200 x(Seal)S(\()S 83 x(\))S 200 x(operation)S
199 x(could)S 4945 X 648 y(not)S 183 x(be)S 182 x(performed)S 183 x
(for)S 183 x(reasons)S 182 x(identi)S -2 x(\211ed)S 182 x(by)S 183 x
(minor_status)S 181 x(codes.)S 3899 X 896 y(\201)S 714 x(NO_CONTEXT)S
235 x(indicates)S 234 x(that)S 235 x(no)S 236 x(valid)S 234 x(context)S
236 x(was)S 235 x(recognized)S 235 x(for)S 236 x(the)S 236 x(inp)S -2 x
(ut)S 236 x(context_)S 4945 X 648 y(handl)S -2 x(e)S 183 x(provided.)S
3899 21298 XY(Performs)S 164 x(the)S 164 x(data)S 162 x(origin)S 162 x
(authentication)S 162 x(and)S 162 x(integrity)S 163 x(functions)S 163 x
(of)S 164 x(Sign)S(\()S 83 x(\))S(.)S 238 x(If)S 164 x(the)S 163 x(input)S
162 x(conf_)S 3899 X 647 y(\212ag)S 219 x(is)S 219 x(TRUE,)S 220 x(addi)S
- -2 x(tionally)S 219 x(app)S -2 x(lies)S 219 x(con\211dential)S -2 x
(ity)S 220 x(to)S 220 x(the)S 220 x(inpu)S -2 x(t_message.)S 355 x(In)S
220 x(all)S 218 x(cases,)S 229 x(this)S 3899 X 648 y(call)S 140 x(yield)S
- -2 x(s)S 141 x(a)S 140 x(single)S 139 x(output_message)S 139 x(data)S
140 x(element)S 140 x(containing)S 139 x(\(optionally)S 140 x(encrypted\))S
140 x(user)S 140 x(data)S 3899 X 647 y(as)S 182 x(well)S 182 x(as)S
182 x(control)S 183 x(information.)S 3899 24635 XY F32(2.3.4)S 547 x
(Unseal)S 182 x(call)S 3899 X 897 y F147(Inputs:)S 3899 X 897 y(\201)S
714 x(context_handle)S 181 x(INTEGER,)S 3899 X 896 y(\201)S 714 x(input_mess)S
- -2 x(age)S 183 x(OCTET)S 183 x(STRING)S 3899 28421 XY(Outputs:)S 3899 X
897 y(\201)S 714 x(conf_\212ag)S 183 x(BOOLEAN,)S 3899 X 896 y(\201)S
714 x(major_status)S 182 x(INTEGER,)S 3899 X 897 y(\201)S 714 x(minor_status)S
182 x(INTEGER,)S 3899 X 897 y(\201)S 714 x(output_messa)S -2 x(ge)S
183 x(OCTET)S 183 x(STRING)S 3899 33104 XY(Return)S 182 x(major_status)S
182 x(values:)S 3899 X 896 y(\201)S 714 x(COMPLETE)S 181 x(indi)S -2 x
(cates)S 180 x(that)S 180 x(the)S 179 x(input_messa)S -2 x(ge)S 181 x
(was)S 179 x(successfully)S 179 x(processed)S 179 x(and)S 179 x(that)S
180 x(the)S 4945 X 648 y(resulting)S 182 x(output_messa)S -2 x(ge)S
183 x(is)S 182 x(availa)S -2 x(ble.)S -651 x 37373 Y F36(28\203February\2031990:)S
222 x(DIGIT)S -37 x(AL)S 167 x(INTERNAL)S 166 x(USE)S 166 x(ONL)S -46 x
(Y)S 498 x(1)S -28 x(1)S
%%EndCustomColor: 0
11 PP EP
%%PageTrailer
%%PageFonts: Helvetica-Bold NewCenturySchlbk-Roman
%%PageCustomColors: 0
%
%%Page: 12 12
%%BeginPageSetup
%%EndPageSetup
%%PageFonts: (atend)
%%PageCustomColors: (atend)
1000 BP PaperHeight PaperWidth PM 0 0 XY 
%%BeginCustomColor: 0 
0 SC 4048 2106 XY F40(Linn:)S 199 x(Generic)S 150 x(Security)S 151 x
(Service)S 150 x(API)S 3899 4006 XY F147(\201)S 714 x(DEFECTIVE_TOKEN)S
275 x(indicates)S 274 x(that)S 276 x(consistency)S 275 x(checks)S 276 x
(performed)S 276 x(on)S 276 x(the)S 276 x(per_msg_)S 4945 X 648 y(token)S
129 x(extracted)S 130 x(from)S 130 x(the)S 129 x(input_mess)S -2 x(age)S
130 x(failed)S -2 x(,)S 141 x(preventing)S 129 x(further)S 130 x(processin)S
- -2 x(g)S 130 x(from)S 130 x(being)S 4945 X 647 y(performed.)S 3899 X
897 y(\201)S 714 x(BAD_SIG)S 183 x(indi)S -2 x(cates)S 183 x(that)S
182 x(an)S 182 x(incorrect)S 183 x(signature)S 182 x(was)S 183 x(detected)S
182 x(for)S 183 x(the)S 183 x(message.)S 3899 X 897 y(\201)S 714 x(DUPLICA)S
- -30 x(TE_TOKEN)S 129 x(indicates)S 127 x(that)S 129 x(the)S 129 x(signature)S
128 x(on)S 128 x(the)S 129 x(per_msg_token)S 129 x(extracted)S 129 x
(from)S 4945 X 647 y(the)S 126 x(inpu)S -2 x(t_message)S 126 x(was)S
125 x(correct)S 128 x(for)S 126 x(the)S 126 x(input)S 125 x(message,)S
137 x(but)S 125 x(that)S 126 x(\(through)S 126 x(means)S 125 x(speci\211c)S
125 x(to)S 4945 X 648 y(mech_type\))S 183 x(the)S 182 x(per_msg_token)S
181 x(was)S 182 x(recognized)S 181 x(as)S 182 x(a)S 182 x(dup)S -2 x
(licate)S 182 x(of)S 182 x(a)S 182 x(previously-processed)S 4945 X 647 y
(per_msg_token.)S 254 x(This)S 185 x(major_status)S 186 x(will)S 185 x
(be)S 186 x(returned)S 186 x(only)S 185 x(for)S 187 x(contexts)S 187 x
(for)S 186 x(which)S 186 x(replay_)S 4945 X 648 y(det_state)S 182 x
(or)S 183 x(sequence_sta)S -2 x(te)S 183 x(is)S 182 x(TRUE.)S 3899 X
897 y(\201)S 714 x(OLD_TO)S 2 x(KEN)S 161 x(indi)S -2 x(cates)S 162 x
(that)S 161 x(the)S 162 x(signature)S 161 x(on)S 161 x(the)S 162 x(per_msg_token)S
161 x(extracted)S 162 x(from)S 163 x(the)S 162 x(in-)S 4945 X 647 y
(put_message)S 132 x(was)S 133 x(correct,)S 145 x(but)S 133 x(that)S
133 x(the)S 133 x(token)S 133 x(is)S 133 x(too)S 133 x(old)S 132 x(to)S
134 x(be)S 133 x(checked)S 133 x(for)S 134 x(dupl)S -2 x(ication.)S
227 x(This)S 4945 X 648 y(major_status)S 164 x(will)S 164 x(be)S 164 x
(returned)S 164 x(only)S 164 x(for)S 166 x(contexts)S 165 x(for)S 165 x
(which)S 164 x(replay_det_state)S 163 x(or)S 165 x(sequence_)S 4945 X
647 y(state)S 182 x(is)S 182 x(TRUE.)S 3899 X 897 y(\201)S 714 x(UNSEQ_TOKEN)S
162 x(indicates)S 161 x(that)S 162 x(the)S 163 x(signature)S 162 x(on)S
162 x(the)S 163 x(per_msg_token)S 162 x(extracted)S 163 x(from)S 164 x
(the)S 4945 X 648 y(input_mess)S -2 x(age)S 220 x(was)S 219 x(correc)S
2 x(t,)S 229 x(but)S 220 x(that)S 219 x(it)S 220 x(is)S 219 x(earlier)S
219 x(in)S 219 x(a)S 220 x(sequenced)S 218 x(stream)S 220 x(than)S 219 x
(a)S 220 x(token)S 4945 X 647 y(already)S 193 x(processed)S 192 x(on)S
194 x(the)S 194 x(context.)S 278 x(This)S 193 x(major_status)S 193 x
(will)S 193 x(be)S 194 x(returned)S 193 x(only)S 194 x(for)S 194 x(contexts)S
4945 X 648 y(for)S 183 x(which)S 183 x(sequence_sta)S -2 x(te)S 183 x
(is)S 182 x(TRUE.)S 3899 X 896 y(\201)S 714 x(CONTEXT_EXPIRED)S 228 x
(indicates)S 227 x(that)S 229 x(context-related)S 229 x(data)S 228 x
(items)S 229 x(have)S 228 x(expired,)S 240 x(so)S 229 x(that)S 4945 X
648 y(the)S 183 x(requested)S 181 x(operation)S 182 x(cannot)S 182 x
(be)S 182 x(performed.)S 3899 X 897 y(\201)S 714 x(CREDEN)S -2 x(TIALS_EXPIRED)S
173 x(indicates)S 171 x(that)S 172 x(the)S 173 x(context)S 173 x(is)S
172 x(recognized,)S 174 x(but)S 173 x(that)S 172 x(its)S 172 x(associ-)S
4945 X 647 y(ated)S 182 x(credentials)S 181 x(have)S 182 x(expired,)S
183 x(so)S 182 x(that)S 182 x(the)S 183 x(requested)S 181 x(operation)S
182 x(cannot)S 182 x(be)S 183 x(performed.)S 3899 X 897 y(\201)S 714 x
(F)S -40 x(AILURE)S 141 x(indicates)S 141 x(that)S 142 x(the)S 142 x
(context)S 143 x(is)S 142 x(recognized,)S 150 x(but)S 142 x(that)S 142 x
(the)S 142 x(Unseal)S(\()S 82 x(\))S 143 x(operation)S 141 x(could)S
4945 X 647 y(not)S 183 x(be)S 182 x(performed)S 183 x(for)S 183 x(reasons)S
182 x(identi)S -2 x(\211ed)S 182 x(by)S 183 x(minor_status)S 181 x(codes.)S
3899 X 897 y(\201)S 714 x(NO_CONTEXT)S 235 x(indicates)S 234 x(that)S
235 x(no)S 236 x(valid)S 234 x(context)S 236 x(was)S 235 x(recognized)S
235 x(for)S 236 x(the)S 236 x(inp)S -2 x(ut)S 236 x(context_)S 4945 X
648 y(handl)S -2 x(e)S 183 x(provided.)S 3899 22636 XY(Processes)S 231 x
(a)S 230 x(data)S 230 x(element)S 231 x(generated)S 230 x(\(and)S 230 x
(optionall)S -2 x(y)S 231 x(encrypted\))S 231 x(by)S 231 x(Seal)S(\()S
83 x(\))S(,)S 244 x(provided)S 229 x(as)S 231 x(in-)S 3899 X 648 y(put_messa)S
- -2 x(ge.)S 388 x(Perfor)S 2 x(ms)S 230 x(decryption)S 230 x(if)S 230 x
(required,)S 242 x(and)S 230 x(then)S 230 x(performs)S 231 x(the)S 230 x
(integrity)S 231 x(and)S 229 x(data)S 3899 X 648 y(origin)S 182 x(authenticati)S
- -2 x(on)S 183 x(checking)S 182 x(functions)S 182 x(of)S 183 x(V)S -51 x
(erify)S(\()S 84 x(\))S 183 x(on)S 182 x(the)S 182 x(resulting)S 182 x
(decrypted)S 182 x(data.)S 242 x(Y)S -24 x(ields)S 3899 X 647 y(decrypted)S
182 x(data)S 182 x(in)S 182 x(output_messa)S -2 x(ge.)S 3899 26074 XY
F28(3)S 598 x(Operationa)S 2 x(l)S 199 x(Scenarios)S 3899 27070 XY F147
(These)S 189 x(discussi)S -2 x(ons)S 189 x(are)S 189 x(intended)S 188 x
(as)S 189 x(examples)S 188 x(for)S 190 x(clari\211cation,)S 190 x(demonstrating)S
189 x(how)S 189 x(API)S 190 x(func-)S 3899 X 647 y(tions)S 241 x(can)S
243 x(be)S 242 x(impl)S -2 x(emented)S 242 x(by)S 242 x(candidate)S
241 x(underlying)S 241 x(mechanisms.)S 422 x(They)S 243 x(should)S 240 x
(not)S 243 x(be)S 242 x(re-)S 3899 X 648 y(garded)S 160 x(as)S 161 x
(constrictive)S 161 x(to)S 161 x(implementatio)S -2 x(ns)S 161 x(or)S
162 x(as)S 160 x(de\211ning)S 160 x(the)S 161 x(only)S 161 x(means)S
160 x(through)S 161 x(which)S 161 x(API)S 3899 X 648 y(functions)S 182 x
(can)S 182 x(be)S 183 x(realiz)S -2 x(ed)S 183 x(with)S 182 x(a)S 182 x
(particular)S 182 x(underlyin)S -2 x(g)S 183 x(technology)S -60 x(.)S
3899 30507 XY F32(3.1)S 547 x(Kerberos)S 182 x(V5,)S 183 x(single-TGT)S
3899 31503 XY F147(OS-speci\211c)S 169 x(login)S 168 x(functions)S 169 x
(yield)S 168 x(a)S 169 x(TGT)S 170 x(to)S 169 x(the)S 169 x(local)S
168 x(realm)S 169 x(Kerberos)S 169 x(server;)S 175 x(TGT)S 170 x(is)S
168 x(placed)S 168 x(in)S 3899 X 648 y(a)S 189 x(credential)S -2 x(s)S
189 x(structure)S 189 x(for)S 190 x(the)S 189 x(client.)S 262 x(Client)S
188 x(calls)S 188 x(Estab_cred)S(\()S 82 x(\))S 190 x(to)S 189 x(acquire)S
188 x(a)S 189 x(cred_hand)S -2 x(le)S 189 x(in)S 3899 X 647 y(order)S
183 x(to)S 182 x(reference)S 184 x(the)S 183 x(credential)S -2 x(s)S
183 x(for)S 183 x(use)S 182 x(in)S 182 x(establis)S -2 x(hing)S 182 x
(security)S 183 x(contexts.)S 3899 33795 XY(Clien)S -2 x(t)S 176 x(calls)S
174 x(Init_sec_context)S(\()S 84 x(\))S(.)S 242 x(If)S 176 x(the)S 175 x
(requested)S 175 x(service)S 175 x(is)S 175 x(located)S 174 x(in)S 175 x
(a)S 175 x(different)S 176 x(realm,)S 177 x(Init_)S 3899 X 647 y(sec_context)S
(\()S 84 x(\))S 227 x(gets)S 227 x(the)S 226 x(necessary)S 226 x(TGT)S
2 x(/key)S 227 x(pai)S -2 x(rs)S 227 x(needed)S 225 x(to)S 227 x(traverse)S
227 x(the)S 226 x(path)S 226 x(from)S 228 x(local)S 225 x(to)S 3899 X
648 y(target)S 233 x(realm;)S 258 x(these)S 232 x(data)S 232 x(are)S
232 x(placed)S 232 x(in)S 232 x(the)S 232 x(owner)S 31 x(')S -21 x(s)S
233 x(TGT)S 234 x(cache.)S 394 x(After)S 233 x(any)S 233 x(needed)S
231 x(remote)S 3899 X 647 y(realm)S 215 x(resolution,)S 222 x(Init_sec_context)S
(\()S 84 x(\))S 215 x(yields)S 214 x(a)S 215 x(service)S 215 x(ticket)S
216 x(to)S 215 x(the)S 215 x(requested)S 214 x(service)S 216 x(with)S
215 x(a)S 3899 37373 XY F36(12)S 498 x(28\203February\2031990:)S 221 x
(DIGIT)S -36 x(AL)S 166 x(INTERNAL)S 166 x(USE)S 166 x(ONL)S -46 x(Y)S
%%EndCustomColor: 0
12 PP EP
%%PageTrailer
%%PageFonts: Helvetica-Bold NewCenturySchlbk-Roman
%%PageCustomColors: 0
%
%%Page: 13 13
%%BeginPageSetup
%%EndPageSetup
%%PageFonts: (atend)
%%PageCustomColors: (atend)
1000 BP PaperHeight PaperWidth PM 0 0 XY 
%%BeginCustomColor: 0 
0 SC 19687 2106 XY F40(Linn:)S 199 x(Generic)S 150 x(Security)S 151 x
(Service)S 150 x(API)S 3899 4006 XY F147(corresponding)S 186 x(session)S
186 x(key;)S 191 x(these)S 187 x(data)S 187 x(are)S 187 x(stored)S 188 x
(in)S 187 x(conjunction)S 187 x(with)S 187 x(the)S 188 x(context.)S
259 x(API)S 188 x(code)S 3899 X 648 y(sends)S 248 x(KRB_TGS_REQ)S 250 x
(request\(s\))S 250 x(and)S 249 x(receives)S 250 x(KRB_TGS_REP)S 250 x
(response\(s\))S 249 x(\(good)S 250 x(case\))S 250 x(or)S 3899 X 647 y
(KRB_ERR)S -2 x(OR.)S 3899 6298 XY(Init_sec_context)S(\()S 83 x(\))S
237 x(buil)S -2 x(ds)S 235 x(a)S 235 x(Kerberos-for)S 2 x(matted)S 235 x
(KRB_AP_REQ)S 235 x(message,)S 248 x(and)S 235 x(returns)S 236 x(it)S
235 x(in)S 3899 X 647 y(output_token.)S 243 x(The)S 183 x(client)S 182 x
(sends)S 181 x(the)S 183 x(output_token)S 182 x(to)S 182 x(the)S 183 x
(service.)S 3899 7942 XY(Service)S 161 x(passe)S -2 x(s)S 161 x(the)S
160 x(received)S 160 x(token)S 161 x(as)S 160 x(the)S 160 x(input_token)S
159 x(of)S 161 x(Accept_sec_context)S(\()S 84 x(\))S(,)S 166 x(which)S
160 x(veri\211es)S 3899 X 647 y(the)S 157 x(authenticator)S -41 x(,)S
163 x(provides)S 157 x(the)S 157 x(service)S 158 x(with)S 157 x(the)S
158 x(client')S -21 x(s)S 157 x(authenticated)S 156 x(name,)S 163 x
(and)S 156 x(returns)S 158 x(an)S 3899 X 648 y(output_context_handl)S
- -2 x(e.)S 3899 10233 XY(Both)S 203 x(parties)S 202 x(now)S 204 x(hold)S
202 x(the)S 204 x(sessi)S -2 x(on)S 204 x(key)S 203 x(associated)S 202 x
(with)S 203 x(the)S 204 x(service)S 203 x(ticket,)S 210 x(and)S 202 x
(can)S 203 x(use)S 203 x(this)S 3899 X 648 y(key)S 183 x(in)S 182 x
(subseq)S -2 x(uent)S 183 x(Sign)S(\()S 83 x(\))S(,)S 183 x(V)S -50 x
(erify)S(\()S 84 x(\))S(,)S 183 x(Seal)S(\()S 83 x(\))S(,)S 183 x(and)S
182 x(Unseal)S -2 x(\()S 84 x(\))S 183 x(operations.)S 3899 12375 XY
F32(3.2)S 547 x(Kerberos)S 182 x(V5,)S 183 x(double-TGT)S 3899 13371 XY
F147(TGT)S 184 x(acquis)S -2 x(ition)S 182 x(as)S 182 x(above.)S 3899 14367 XY
(Note:)S 231 x(T)S -50 x(o)S 157 x(avoid)S 157 x(unnecessa)S -2 x(ry)S
158 x(frequent)S 158 x(invocations)S 156 x(of)S 158 x(error)S 158 x
(paths)S 157 x(when)S 157 x(implementi)S -2 x(ng)S 158 x(the)S 157 x
(API)S 3899 X 648 y(atop)S 224 x(Kerberos)S 226 x(V5,)S 236 x(it)S 225 x
(seems)S 224 x(appropria)S -2 x(te)S 226 x(to)S 225 x(represent)S 225 x
("single-TGT)S 226 x(K-V5")S 226 x(and)S 224 x("double-TGT)S 3899 X
648 y(K-V5")S 183 x(with)S 182 x(separate)S 182 x(mech_types,)S 182 x
(and)S 182 x(this)S 182 x(discuss)S -2 x(ion)S 182 x(makes)S 182 x(that)S
183 x(assump)S -2 x(tion.)S 3899 16659 XY(Based)S 271 x(on)S 271 x(the)S
273 x(\(speci\211ed)S 271 x(or)S 272 x(defaulted\))S 271 x(mech_type,)S
295 x(Init_sec_context)S(\()S 84 x(\))S 272 x(determines)S 272 x(that)S
272 x(the)S 3899 X 647 y(doubl)S -2 x(e-TG)S 2 x(T)S 170 x(protocol)S
170 x(should)S 168 x(be)S 170 x(employed)S 169 x(for)S 171 x(the)S 170 x
(speci\211ed)S 168 x(target.)S 240 x(Init_sec_context)S(\()S 84 x(\))S
170 x(returns)S 3899 X 648 y(RETR)S -21 x(Y_NEE)S -2 x(DED)S 231 x(major_status,)S
242 x(and)S 230 x(its)S 230 x(returned)S 230 x(output_token)S 230 x
(contains)S 230 x(a)S 230 x(request)S 230 x(to)S 231 x(the)S 3899 X
648 y(service)S 152 x(for)S 152 x(the)S 152 x(service')S -21 x(s)S 152 x
(TGT)S -49 x(.)S 152 x(\(If)S 152 x(a)S 152 x(service)S 152 x(TGT)S
152 x(with)S 152 x(suitabl)S -2 x(y)S 152 x(long)S 151 x(remaining)S
151 x(lifetime)S 152 x(alread)S -2 x(y)S 3899 X 647 y(exists)S 190 x
(in)S 191 x(a)S 191 x(cache,)S 193 x(it)S 191 x(may)S 191 x(be)S 191 x
(usabl)S -2 x(e,)S 194 x(obviatin)S -2 x(g)S 192 x(the)S 191 x(need)S
190 x(for)S 192 x(this)S 190 x(step.\))S 269 x(The)S 192 x(client)S
190 x(passes)S 190 x(the)S 3899 X 648 y(output_token)S 182 x(to)S 182 x
(the)S 183 x(service.)S 3899 20893 XY(The)S 157 x(service)S 158 x(pas)S
- -2 x(ses)S 157 x(the)S 157 x(received)S 157 x(token)S 157 x(as)S 157 x
(the)S 157 x(inp)S -2 x(ut_token)S 157 x(argument)S 158 x(to)S 157 x
(Accept_sec_context)S(\()S 84 x(\))S(,)S 3899 X 648 y(which)S 192 x
(recognizes)S 192 x(it)S 192 x(as)S 192 x(a)S 192 x(request)S 192 x
(for)S 193 x(TGT)S -49 x(.)S 193 x(\(Note)S 192 x(that)S 193 x(current)S
193 x(Kerberos)S 192 x(V5)S 192 x(de\211nes)S 191 x(no)S 193 x(intra-)S
3899 X 647 y(protocol)S 246 x(mechanism)S 246 x(to)S 247 x(represent)S
247 x(such)S 246 x(a)S 247 x(request.\))S 436 x(Accept_sec_context)S
(\()S 84 x(\))S 247 x(returns)S 247 x(RETR)S -21 x(Y_)S 3899 X 648 y
(NEEDED)S 247 x(major_status)S 248 x(and)S 248 x(provides)S 247 x(the)S
249 x(service')S -21 x(s)S 248 x(TGT)S 250 x(in)S 248 x(its)S 248 x
(output_token.)S 441 x(The)S 248 x(service)S 3899 X 647 y(sends)S 181 x
(the)S 183 x(output_token)S 182 x(to)S 182 x(the)S 183 x(client.)S 3899 24480 XY
(The)S 231 x(client)S 230 x(passes)S 229 x(the)S 231 x(received)S 231 x
(token)S 230 x(as)S 230 x(the)S 231 x(input_token)S 230 x(argument)S
231 x(to)S 230 x(a)S 231 x(retry)S 232 x(of)S 231 x(Init_sec_)S 3899 X
647 y(context)S(\()S 84 x(\))S(.)S 234 x(Init_sec_context)S(\()S 84 x
(\))S 154 x(caches)S 152 x(the)S 154 x(received)S 153 x(service)S 153 x
(TGT)S 154 x(and)S 152 x(uses)S 153 x(it)S 153 x(as)S 152 x(part)S 153 x
(of)S 154 x(a)S 152 x(service)S 3899 X 648 y(ticket)S 176 x(request)S
176 x(to)S 177 x(the)S 176 x(Kerberos)S 177 x(server)S -40 x(,)S 178 x
(storing)S 176 x(the)S 176 x(returned)S 176 x(service)S 177 x(ticket)S
176 x(and)S 176 x(sessi)S -2 x(on)S 177 x(key)S 176 x(in)S 3899 X 647 y
(conjunction)S 173 x(with)S 173 x(the)S 174 x(context.)S 241 x(Init_sec_context)S
(\()S 84 x(\))S 174 x(buil)S -2 x(ds)S 173 x(a)S 173 x(Kerberos-formatted)S
174 x(authenticator)S -41 x(,)S 3899 X 648 y(and)S 248 x(returns)S 249 x
(it)S 250 x(in)S 248 x(output_token)S 249 x(along)S 248 x(with)S 250 x
(COMPLETE)S 250 x(return)S 249 x(major_status.)S 443 x(The)S 250 x(client)S
3899 X 647 y(sends)S 181 x(the)S 183 x(output_token)S 182 x(to)S 182 x
(the)S 183 x(service.)S 3899 28714 XY(Service)S 212 x(pas)S -2 x(ses)S
211 x(the)S 211 x(received)S 211 x(token)S 211 x(as)S 210 x(the)S 211 x
(input_token)S 210 x(argument)S 211 x(to)S 211 x(another)S 211 x(call)S
210 x(to)S 212 x(Accept_)S 3899 X 647 y(sec_context)S(\()S 84 x(\))S
(.)S 507 x(Accept_sec_context)S(\()S 83 x(\))S 271 x(veri\211es)S 270 x
(the)S 270 x(authenti)S -2 x(cator)S -40 x(,)S 293 x(provides)S 268 x
(the)S 270 x(service)S 271 x(with)S 3899 X 648 y(the)S 217 x(client')S
- -22 x(s)S 217 x(authenticated)S 215 x(name,)S 225 x(and)S 216 x(returns)S
217 x(an)S 216 x(output_context_hand)S -2 x(le)S 217 x(along)S 216 x
(with)S 216 x(return)S 3899 X 647 y(major_status)S 182 x(COMPLETE.)S
3899 31653 XY(Sign)S(\()S 83 x(\))S(,)S 184 x(V)S -51 x(erify)S(\()S
84 x(\))S(,)S 183 x(Seal)S(\()S 83 x(\))S(,)S 184 x(and)S 181 x(Unseal)S
(\()S 82 x(\))S 183 x(as)S 182 x(above.)S 14091 37373 XY
F36(28\203February\2031990:)S
221 x(DIGIT)S -36 x(AL)S 166 x(INTERNAL)S 166 x(USE)S 166 x(ONL)S -46 x
(Y)S 499 x(13)S
%%EndCustomColor: 0
13 PP EP
%%PageTrailer
%%PageFonts: Helvetica-Bold NewCenturySchlbk-Roman
%%PageCustomColors: 0
%
%%Page: 14 14
%%BeginPageSetup
%%EndPageSetup
%%PageFonts: (atend)
%%PageCustomColors: (atend)
1000 BP PaperHeight PaperWidth PM 0 0 XY 
%%BeginCustomColor: 0 
0 SC 4048 2106 XY F40(Linn:)S 199 x(Generic)S 150 x(Security)S 151 x
(Service)S 150 x(API)S 3899 4032 XY F28(4)S 598 x(Acknowled)S 2 x(gments)S
3899 5028 XY F147(This)S 261 x(proposa)S -2 x(l)S 261 x(is)S 261 x(the)S
261 x(result)S 261 x(of)S 262 x(a)S 261 x(collaborative)S 260 x(effort.)S
481 x(Special)S 261 x(thanks)S 260 x(for)S 262 x(contributions)S 260 x
(to)S 3899 X 647 y(this)S 169 x(version)S 169 x(are)S 169 x(due)S 169 x
(to)S 170 x(Kannan)S 168 x(Alagapp)S -2 x(an,)S 172 x(Bill)S 168 x(Brown,)S
173 x(Charl)S -2 x(ie)S 170 x(Kaufman,)S 172 x(Butler)S 169 x(Lampson,)S
3899 X 648 y(Richard)S 122 x(Pitkin,)S 136 x(and)S 122 x(Joe)S 123 x
(T)S -33 x(ardo,)S 135 x(of)S 124 x(Digital)S 123 x(Equip)S -2 x(ment)S
124 x(Corporation.)S 223 x(John)S 123 x(Kohl)S 123 x(and)S 123 x(Jon)S
123 x(Rochlis)S 3899 X 648 y(contributed)S 161 x(valuable)S 161 x(insights)S
- -2 x(.)S 238 x(Joe)S 161 x(Pato)S 163 x(and)S 161 x(Bill)S 161 x(Sommerfeld)S
163 x(of)S 162 x(HP/)S 2 x(Apol)S -2 x(lo)S 162 x(provided)S 161 x(input)S
161 x(to)S 3899 X 647 y(earlier)S 182 x(discuss)S -2 x(ions)S 182 x
(which)S 182 x(helped)S 181 x(to)S 183 x(focus)S 183 x(API)S 183 x(directions.)S
3899 37373 XY F36(14)S 498 x(28\203February\2031990:)S 221 x(DIGIT)S
- -36 x(AL)S 166 x(INTERNAL)S 166 x(USE)S 166 x(ONL)S -46 x(Y)S
%%EndCustomColor: 0
14 PP EP
%%PageTrailer
%%PageFonts: Helvetica-Bold NewCenturySchlbk-Roman
%%PageCustomColors: 0
%
%%Trailer
EndDVC$PSDoc
/DEC$EDMS_MAKE_FILM where	% if we are making film...
 { pop				% ..clean up the stack
   -54 dup translate		% ..undo the film translation
 } if
%%Pages: 14
%%DocumentFonts: NewCenturySchlbk-Roman
%%+ Helvetica-Bold
%%DocumentCustomColors: 0

------- End of Forwarded Message


1,,
Summary-line:  2-Mar  John T Kohl                #Re: Generic Authentication Interface
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA29122; Fri, 2 Mar 90 12:06:13 EST
Received: from LYCUS.MIT.EDU by ATHENA.MIT.EDU with SMTP
	id AA07428; Fri, 2 Mar 90 12:06:48 EST
Received: by lycus.MIT.EDU (5.61/4.7) id AA14963; Fri, 2 Mar 90 12:05:54 -0500
Date: Fri, 2 Mar 90 12:05:54 -0500
From: John T Kohl <jtkohl@ATHENA.MIT.EDU>
Message-Id: <9003021705.AA14963@lycus.MIT.EDU>
To: bbrown@DECVAX.DEC.COM
In-Reply-To: bbrown@DECVAX.DEC.COM's message of Thu, 01 Mar 90 16:15:00 EST,
	<9003012115.AA12109@abyss.zk3.dec.com>
Subject: Re: Generic Authentication Interface
X-Us-Snail: MIT Room E40-351, 1 Amherst St., Cambridge, MA 02139 USA

*** EOOH ***
Date: Fri, 2 Mar 90 12:05:54 -0500
From: John T Kohl <jtkohl@ATHENA.MIT.EDU>
To: bbrown@DECVAX.DEC.COM
In-Reply-To: bbrown@DECVAX.DEC.COM's message of Thu, 01 Mar 90 16:15:00 EST,
	<9003012115.AA12109@abyss.zk3.dec.com>
Subject: Re: Generic Authentication Interface

Thanks for forwarding it on.  I won't be able to look at it until
sometime mid/late next week as I'm busy with Athena/OSF stuff.

Can I distribute copies to the MIT network people (Jeff Schiller & Jon
Rochlis)?

John

1,,
Summary-line:  5-Mar  05-Mar-1990 1225           #background on security document
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA14633; Mon, 5 Mar 90 12:26:56 EST
Received: from decwrl.dec.com by ATHENA.MIT.EDU with SMTP
	id AA02751; Mon, 5 Mar 90 12:27:49 EST
Received: by decwrl.dec.com; id AA05412; Mon, 5 Mar 90 09:26:10 -0800
Message-Id: <9003051726.AA05412@decwrl.dec.com>
Received: from rdvax.enet; by decwrl.enet; Mon, 5 Mar 90 09:26:22 PST
Date: Mon, 5 Mar 90 09:26:22 PST
From: 05-Mar-1990 1225 <champine@RDVAX.ENET.DEC.COM>
To: geer@DECWRL.DEC.COM, jtkohl@DECWRL.DEC.COM
Subject: background on security document

*** EOOH ***
Date: Mon, 5 Mar 90 09:26:22 PST
From: 05-Mar-1990 1225 <champine@RDVAX.ENET.DEC.COM>
To: geer@DECWRL.DEC.COM, jtkohl@DECWRL.DEC.COM
Subject: background on security document

From:	ULTRA::LINN "John Linn. 508-264-5491. DTN 293-5491.  05-Mar-1990 1133"  5-MAR-1990 11:34:41.27
To:	CRL::AUTH-API-EXT
CC:	@APICC,LINN
Subj:	Generic security service API proposal to follow

API-interested folk:

Following this cover message, you will receive another message, containing a
PostScript document entitled "Generic Security Service Application Program
Interface", and designated Version C.1 to distinguish it from predecessor
versions.  Feel free to redistribute it to other interested readers.

This document presents a concrete proposal for an API providing a range of
security services (authentication, integrity, and confidentiality) to calling
applications, yet insulating those calling applications from specifics of
underlying mechanisms. The document draws on prior discussions carried on in
the ad hoc API group and elsewhere, and attempts to meld disparate goals into a
self-consistent whole.

If you have difficulty accomodating a PostScript document, let me
(Linn@ultra.enet.dec.com) know; I can send you a hard copy or an electronically
mailable (but unaesthetic and differently paginated) pure-ASCII version.

We're looking towards scheduling a meeting to review this proposal in Cambridge
later this month, and encourage any interested parties to attend.  A scheduling
announcement will be forthcoming. Written comments are also encouraged, to me
or to the auth-api-ext mailing list exploded at crl.

Thanks for your interest in this proposal and in the issues it addresses.

--jl

1,,
Summary-line:  5-Mar  3-5491.  05-Mar-1990 1133  #Generic security service API proposal to follow
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA17656; Mon, 5 Mar 90 20:31:42 EST
Received: from crl.dec.com by ATHENA.MIT.EDU with SMTP
	id AA01310; Mon, 5 Mar 90 20:31:26 EST
Received: by crl.dec.com; id AA05427; Mon, 5 Mar 90 17:41:00 -0500
Received: by crltrx.crl.dec.com; id AA19891; Mon, 5 Mar 90 17:40:50 -0500
Received: by crltrx.crl.dec.com; id AA19877; Mon, 5 Mar 90 17:40:37 -0500
Received: by easynet.crl.dec.com; id AA00588; Mon, 5 Mar 90 17:37:28 -0500
Date: Mon, 5 Mar 90 17:37:25 -0500
Message-Id: <9003052237.AA00588@easynet.crl.dec.com>
From: linn@ultra.enet.dec.com (John Linn. 508-264-5491. DTN 293-5491.  05-Mar-1990 1133)
To: auth-api-ext@CRL.DEC.COM
Cc: @APICC@crltrx.dec.com, LINN@CRL.DEC.COM
Subject: Generic security service API proposal to follow

*** EOOH ***
Date: Mon, 5 Mar 90 17:37:25 -0500
From: linn@ultra.enet.dec.com (John Linn. 508-264-5491. DTN 293-5491.  05-Mar-1990 1133)
To: auth-api-ext@CRL.DEC.COM
Cc: @APICC@crltrx.dec.com, LINN@CRL.DEC.COM
Subject: Generic security service API proposal to follow

API-interested folk:

Following this cover message, you will receive another message, containing a
PostScript document entitled "Generic Security Service Application Program
Interface", and designated Version C.1 to distinguish it from predecessor
versions.  Feel free to redistribute it to other interested readers.

This document presents a concrete proposal for an API providing a range of
security services (authentication, integrity, and confidentiality) to calling
applications, yet insulating those calling applications from specifics of
underlying mechanisms. The document draws on prior discussions carried on in
the ad hoc API group and elsewhere, and attempts to meld disparate goals into a
self-consistent whole.

If you have difficulty accomodating a PostScript document, let me
(Linn@ultra.enet.dec.com) know; I can send you a hard copy or an electronically
mailable (but unaesthetic and differently paginated) pure-ASCII version.

We're looking towards scheduling a meeting to review this proposal in Cambridge
later this month, and encourage any interested parties to attend.  A scheduling
announcement will be forthcoming. Written comments are also encouraged, to me
or to the auth-api-ext mailing list exploded at crl.

Thanks for your interest in this proposal and in the issues it addresses.

--jl


1,answered,,
Summary-line:  6-Mar  3-5491.  06-Mar-1990 1408  #Looking ahead to API proposal discussion
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA24227; Tue, 6 Mar 90 14:32:50 EST
Received: from decwrl.dec.com by ATHENA.MIT.EDU with SMTP
	id AA20153; Tue, 6 Mar 90 14:31:24 EST
Received: by decwrl.dec.com; id AA04785; Tue, 6 Mar 90 11:31:05 -0800
Received: by easynet.crl.dec.com; id AA01017; Tue, 6 Mar 90 14:28:05 -0500
Date: Tue, 6 Mar 90 14:28:02 -0500
Message-Id: <9003061928.AA01017@easynet.crl.dec.com>
From: linn@ULTRA.ENET.DEC.COM (John Linn. 508-264-5491. DTN 293-5491.  06-Mar-1990 1408)
To: "jon@mit.edu"@CRL.DEC.COM, "jis@mit.edu"@CRL.DEC.COM,
        "jtkohl@athena.mit.edu"@CRL.DEC.COM
Cc: LINN@CRL.DEC.COM
Subject: Looking ahead to API proposal discussion

*** EOOH ***
Date: Tue, 6 Mar 90 14:28:02 -0500
From: linn@ULTRA.ENET.DEC.COM (John Linn. 508-264-5491. DTN 293-5491.  06-Mar-1990 1408)
To: "jon@mit.edu"@CRL.DEC.COM, "jis@mit.edu"@CRL.DEC.COM,
        "jtkohl@athena.mit.edu"@CRL.DEC.COM
Cc: LINN@CRL.DEC.COM
Subject: Looking ahead to API proposal discussion

Cantabrigian API-ers:

At the last API meeting at DEC-CRL on 25 January, Jon Rochlis suggested that it
might be appropriate to hold a design review with the Kerberos group at MIT
once a sufficiently concrete proposal was available, given a 2-3 week reading
period in advance.  My intent was that the document I mailed yesterday would be
suitably concrete to serve as the basis for a productive review; please let me
know if you perceive gaping holes in its scope for this purpose.

I'm trying to organize a month's hectic calendar; does Jon's proposed approach
still seem appropriate, and would 28 March (or some other day that week) be a
plausible candidate date for a review?

Thanks, regards, ...

--jl

1,,
Summary-line:  6-Mar  John T Kohl                #Re: Looking ahead to API proposal discussion
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA26076; Tue, 6 Mar 90 17:42:50 EST
Received: from LYCUS.MIT.EDU by ATHENA.MIT.EDU with SMTP
	id AA27043; Tue, 6 Mar 90 17:42:39 EST
Received: by lycus.MIT.EDU (5.61/4.7) id AA10411; Tue, 6 Mar 90 17:42:28 -0500
Date: Tue, 6 Mar 90 17:42:28 -0500
From: John T Kohl <jtkohl@ATHENA.MIT.EDU>
Message-Id: <9003062242.AA10411@lycus.MIT.EDU>
To: linn@ULTRA.ENET.DEC.COM
Cc: jon@ATHENA.MIT.EDU, jis@ATHENA.MIT.EDU
In-Reply-To: John Linn. 508-264-5491. DTN 293-5491.  06-Mar-1990 1408's message of Tue, 6 Mar 90 14:28:02 -0500,
	<9003061928.AA01017@easynet.crl.dec.com>
Subject: Re: Looking ahead to API proposal discussion
X-Us-Snail: MIT Room E40-351, 1 Amherst St., Cambridge, MA 02139 USA

*** EOOH ***
Date: Tue, 6 Mar 90 17:42:28 -0500
From: John T Kohl <jtkohl@ATHENA.MIT.EDU>
To: linn@ULTRA.ENET.DEC.COM
Cc: jon@ATHENA.MIT.EDU, jis@ATHENA.MIT.EDU
In-Reply-To: John Linn. 508-264-5491. DTN 293-5491.  06-Mar-1990 1408's message of Tue, 6 Mar 90 14:28:02 -0500,
	<9003061928.AA01017@easynet.crl.dec.com>
Subject: Re: Looking ahead to API proposal discussion

I can probably make it some day that week, but I may be out of town for
a day or two that week (not yet certain if or when).

John

1,answered,,
Summary-line: 23-Mar  an Schimpf - DTN 226-5292  #Meeting next Wednesday
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA22195; Fri, 23 Mar 90 10:50:27 EST
Received: from crl.dec.com by ATHENA.MIT.EDU with SMTP
	id AA18741; Fri, 23 Mar 90 10:50:23 EST
Received: by crl.dec.com; id AA16602; Fri, 23 Mar 90 10:50:18 -0500
Received: by crltrx.crl.dec.com; id AA04270; Fri, 23 Mar 90 10:50:07 -0500
Received: by crltrx.crl.dec.com; id AA04250; Fri, 23 Mar 90 10:49:56 -0500
Received: by easynet.crl.dec.com; id AA25530; Fri, 23 Mar 90 10:45:10 -0500
Date: Fri, 23 Mar 90 10:45:08 -0500
Message-Id: <9003231545.AA25530@easynet.crl.dec.com>
From: schimpf@took.enet.dec.com (Brian Schimpf - DTN 226-5292)
To: auth-api-ext@crl.dec.com
Cc: SCHIMPF@crl.dec.com
Subject: Meeting next Wednesday

*** EOOH ***
Date: Fri, 23 Mar 90 10:45:08 -0500
From: schimpf@took.enet.dec.com (Brian Schimpf - DTN 226-5292)
To: auth-api-ext@crl.dec.com
Cc: SCHIMPF@crl.dec.com
Subject: Meeting next Wednesday

	Reminder that we are planning to have a meeting next Wednesday, March 28
starting at 9:00 to continue our discussions of the generic authentication
interface, in particular the proposal sent out by John Linn a couple of weeks
ago.  I am trying to confirm with some of the key players and make sure we have
the right folks there.  The meeting will be held at Digital's Cambridge
Research Lab at One Kendall Square.

Thanks,

Brian Schimpf


1,,
Summary-line: 15-Mar  an Schimpf - DTN 226-5292  #Next Athena meeting
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA29479; Thu, 15 Mar 90 08:25:20 EST
Received: from crl.dec.com by ATHENA.MIT.EDU with SMTP
	id AA19143; Thu, 15 Mar 90 08:25:17 EST
Received: by crl.dec.com; id AA09263; Thu, 15 Mar 90 08:25:13 -0500
Received: by crltrx.crl.dec.com; id AA04240; Thu, 15 Mar 90 08:25:03 -0500
Received: by crltrx.crl.dec.com; id AA04232; Thu, 15 Mar 90 08:24:59 -0500
Received: by easynet.crl.dec.com; id AA11466; Thu, 15 Mar 90 08:20:22 -0500
Date: Thu, 15 Mar 90 08:20:20 -0500
Message-Id: <9003151320.AA11466@easynet.crl.dec.com>
From: schimpf@took.enet.dec.com (Brian Schimpf - DTN 226-5292)
To: auth-api-ext@crl.dec.com
Cc: SCHIMPF@crl.dec.com
Subject: Next Athena meeting

*** EOOH ***
Date: Thu, 15 Mar 90 08:20:20 -0500
From: schimpf@took.enet.dec.com (Brian Schimpf - DTN 226-5292)
To: auth-api-ext@crl.dec.com
Cc: SCHIMPF@crl.dec.com
Subject: Next Athena meeting

	We have tentatively scheduled the next common authentication interface
meeting for Wednesday morning, March 28, 1990.  The meeting will start at 9:00
AM at the Digital Cambridge Research Lab at One Kendall Square in Cambridge.
If this time is not convenient for you please let me know.

Thanks,

Brian Schimpf


1,,
Summary-line: 23-Mar  John T Kohl                #Re: Meeting next Wednesday
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA22790; Fri, 23 Mar 90 11:58:40 EST
Received: from LYCUS.MIT.EDU by ATHENA.MIT.EDU with SMTP
	id AA20560; Fri, 23 Mar 90 11:58:37 EST
Received: by lycus.MIT.EDU (5.61/4.7) id AA23779; Fri, 23 Mar 90 11:58:32 -0500
Date: Fri, 23 Mar 90 11:58:32 -0500
From: John T Kohl <jtkohl@ATHENA.MIT.EDU>
Message-Id: <9003231658.AA23779@lycus.MIT.EDU>
To: schimpf@took.enet.dec.com
In-Reply-To: Brian Schimpf - DTN 226-5292's message of Fri, 23 Mar 90 10:45:08 -0500,
	<9003231545.AA25530@easynet.crl.dec.com>
Subject: Re: Meeting next Wednesday
X-Us-Snail: MIT Room E40-300, 1 Amherst St., Cambridge, MA 02139 USA

*** EOOH ***
Date: Fri, 23 Mar 90 11:58:32 -0500
From: John T Kohl <jtkohl@ATHENA.MIT.EDU>
To: schimpf@took.enet.dec.com
In-Reply-To: Brian Schimpf - DTN 226-5292's message of Fri, 23 Mar 90 10:45:08 -0500,
	<9003231545.AA25530@easynet.crl.dec.com>
Subject: Re: Meeting next Wednesday

I am planning on attending; I believe Jeff Schiller and Jon Rochlis from
MIT are also planning on attending.

John

1,,
Summary-line: 23-Mar  an Schimpf - DTN 226-5292  #Meeting confirmation
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA23267; Fri, 23 Mar 90 13:09:03 EST
Received: from crl.dec.com by ATHENA.MIT.EDU with SMTP
	id AA22409; Fri, 23 Mar 90 13:08:59 EST
Received: by crl.dec.com; id AA17189; Fri, 23 Mar 90 13:08:55 -0500
Received: by crltrx.crl.dec.com; id AA07701; Fri, 23 Mar 90 13:08:51 -0500
Received: by crltrx.crl.dec.com; id AA07694; Fri, 23 Mar 90 13:08:45 -0500
Received: by easynet.crl.dec.com; id AA26041; Fri, 23 Mar 90 13:05:44 -0500
Date: Fri, 23 Mar 90 13:05:41 -0500
Message-Id: <9003231805.AA26041@easynet.crl.dec.com>
From: schimpf@took.enet.dec.com (Brian Schimpf - DTN 226-5292)
To: auth-api-ext@crl.dec.com
Cc: SCHIMPF@crl.dec.com
Subject: Meeting confirmation

*** EOOH ***
Date: Fri, 23 Mar 90 13:05:41 -0500
From: schimpf@took.enet.dec.com (Brian Schimpf - DTN 226-5292)
To: auth-api-ext@crl.dec.com
Cc: SCHIMPF@crl.dec.com
Subject: Meeting confirmation

	Just wanted to confirm that the authentication discussion *will* take
place this coming Wednesday, March 28.  We will begin at 9:00 AM in the Mojave
conference room at Digital's Cambridge Research Lab at One Kendall Square in
Cambridge.

Thanks,

Brian Schimpf


1,,
Summary-line: 23-Mar  an Schimpf - DTN 226-5292  #Meeting next week
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA26066; Fri, 23 Mar 90 18:42:31 EST
Received: from decwrl.dec.com by ATHENA.MIT.EDU with SMTP
	id AA02751; Fri, 23 Mar 90 18:42:26 EST
Received: by decwrl.dec.com; id AA23746; Fri, 23 Mar 90 07:43:24 -0800
Message-Id: <9003231543.AA23746@decwrl.dec.com>
Received: from took.enet; by decwrl.enet; Fri, 23 Mar 90 07:45:50 PST
Date: Fri, 23 Mar 90 07:45:50 PST
From: Brian Schimpf - DTN 226-5292 <schimpf@took.enet.dec.com>
To: jtkohl@ATHENA.MIT.EDU, jis@mit.edu
Cc: schimpf@decwrl.dec.com
Subject: Meeting next week

*** EOOH ***
Date: Fri, 23 Mar 90 07:45:50 PST
From: Brian Schimpf - DTN 226-5292 <schimpf@took.enet.dec.com>
To: jtkohl@ATHENA.MIT.EDU, jis@mit.edu
Cc: schimpf@decwrl.dec.com
Subject: Meeting next week

John and Jeff,

	I'm just trying to finalize the meeting proposed for next Wednesday
to continue the discussions on the generic authentication API.  Are you guys
planning on being there?

Thanks,

Brian

1,,
Summary-line: 22-Mar  John T Kohl                #AT&T authentication API
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA17381; Thu, 22 Mar 90 17:06:02 EST
Received: from LYCUS.MIT.EDU by ATHENA.MIT.EDU with SMTP
	id AA02837; Thu, 22 Mar 90 17:05:59 EST
Received: by lycus.MIT.EDU (5.61/4.7) id AA19096; Thu, 22 Mar 90 17:05:56 -0500
Date: Thu, 22 Mar 90 17:05:56 -0500
From: John T Kohl <jtkohl@ATHENA.MIT.EDU>
Message-Id: <9003222205.AA19096@lycus.MIT.EDU>
To: steiner@osf.org
Subject: AT&T authentication API
X-Us-Snail: MIT Room E40-300, 1 Amherst St., Cambridge, MA 02139 USA

*** EOOH ***
Date: Thu, 22 Mar 90 17:05:56 -0500
From: John T Kohl <jtkohl@ATHENA.MIT.EDU>
To: steiner@osf.org
Subject: AT&T authentication API

Do you have the name/e-mail addr of the people at AT&T we should contact
about authentiacation API work?

John

1,,
Summary-line: 17-Apr  John T Kohl                #API comments
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA03974; Tue, 17 Apr 90 15:48:44 EST
Received: from crl.dec.com by ATHENA.MIT.EDU with SMTP
	id AA00203; Tue, 17 Apr 90 16:48:40 EDT
Received: by crl.dec.com; id AA07169; Tue, 17 Apr 90 16:48:35 -0400
Received: by crltrx.crl.dec.com; id AA07912; Tue, 17 Apr 90 16:48:27 -0400
Date: Tue, 17 Apr 90 16:48:27 -0400
From: jtkohl@crl.dec.com (John T Kohl)
Message-Id: <9004172048.AA07912@crltrx.crl.dec.com>
To: linn@ultra.enet.dec.com
Subject: API comments
X-Us-Snail: MIT Room E40-321, 1 Amherst St., Cambridge, MA 02139 USA

*** EOOH ***
Date: Tue, 17 Apr 90 16:48:27 -0400
From: jtkohl@crl.dec.com (John T Kohl)
To: linn@ultra.enet.dec.com
Subject: API comments

Sorry these are so late, I've been quite busy, as I am sure we all have
been.  These are all relative to Version c.1: 5 Marh 1990

In general:
I don't particularly care for some of your names for the parameters; I
can send you my suggestions if you wish.

Some (most?) of the octet strings would more naturally be (void *) in C.

Sign & Unsign won't work with existing Kerberos v4 or v5 packet formats;
the integrity-only checks don't provide a way to separate the integrity
check info from the data.

Seal & Unseal, as a consequence, would require two mechanisms in v4/v5,
to support both the KRB_SAFE and KRB_PRIV messages.

The error code NO_CONTEXT is appropriate for all of the calls except
init_sec_context.

Estab_cred:
There would seem to need to be 2 versions of this in the Kerberos world,
since server keys are not stored in the same way that client tickets are
stored.  Any good way to distinguish between the flavors in the API?

any good reason why timedelta shouldn't be in seconds?

init_sec_context:
the input_context_handle should be a void * in the C world; likewise
output_context_handle should be a void **.

in the prose, you talk about mutual_req_state; that should be
mutual_state.


accept_sec_context:
input_ & output_context_handle again should be void */**

How do we specify a channel-binding in a generic way, taking into
account the need for multiple address types, etc. even within a
particular mechanism?

delete_sec_context:
in the prose, you talk about a "member" of the context; "peer" would be
a better word.


1,,
Summary-line: 24-Apr  an Schimpf - DTN 226-5292  #Minutes of March 28, 1990 meeting
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA15387; Tue, 24 Apr 90 09:01:43 EST
Received: from crl.dec.com by ATHENA.MIT.EDU with SMTP
	id AA17497; Tue, 24 Apr 90 10:01:40 EDT
Received: by crl.dec.com; id AA08437; Tue, 24 Apr 90 10:01:33 -0400
Received: by crltrx.crl.dec.com; id AA13222; Tue, 24 Apr 90 10:01:30 -0400
Received: by crltrx.crl.dec.com; id AA13216; Tue, 24 Apr 90 10:01:24 -0400
Received: by easynet.crl.dec.com; id AA15971; Tue, 24 Apr 90 05:52:57 -0400
Date: Tue, 24 Apr 90 05:52:53 -0400
Message-Id: <9004240952.AA15971@easynet.crl.dec.com>
From: schimpf@took.enet.dec.com (Brian Schimpf - DTN 226-5292)
To: auth-api-ext@crl.dec.com
Cc: SCHIMPF@crl.dec.com
Subject: Minutes of March 28, 1990 meeting

*** EOOH ***
Date: Tue, 24 Apr 90 05:52:53 -0400
From: schimpf@took.enet.dec.com (Brian Schimpf - DTN 226-5292)
To: auth-api-ext@crl.dec.com
Cc: SCHIMPF@crl.dec.com
Subject: Minutes of March 28, 1990 meeting


+---+---+---+---+---+---+---+
| d | i | g | i | t | a | l |     I N T E R O F F I C E   M E M O
+---+---+---+---+---+---+---+


                                   Date:  April 24, 1990
                                   From:  Brian C. Schimpf
                                   Dept:  Distributed Processing Engineering
                                   Phone: (508) 486-5292
                                   Decnet:  TOOK::SCHIMPF
                                   Mail Stop:  LKG2-2/Z7

To:	  Mailing list

Subject:  Meeting to discuss common authentication interface

	A fourth meeting was held on the topic of a common authentication
programming interface.  The meeting was held on Wednesday, March 28, 1990 at
Digital's Cambridge Research Lab.  Attendees at the meeting were:

	Bill Brown		Digital (ULTRIX)
	Bill Griffeth		AT&T
	Charlie Kaufman		Digital (Telecommunications and Networking)
	John Kohl		MIT/Project Athena
	John Linn		Digital (Secure Systems)
	Mike Merritt		AT&T
	Joe Pato		HP/Apollo
	Richard Pitkin		Digital (Distributed Processing)
	Jeff Schiller		MIT/Project Athena
	Brian Schimpf		Digital (Distributed Processing)
	Bill Sommerfeld		HP/Apollo
	Jennifer Steiner	OSF
	Walt Tuvell		OSF
	John Williams		Digital (ULTRIX)


	This was the first meeting which Bill and Mike from AT&T had been able
to attend.  Mike was added to the mailing list ("mischu@research.att.com");
Bill had already been on the mailing list.  Given the presence of some new
players all the attendees introduced themselves.  A rough agenda of topics to
be addressed was put together:

  * Background on the GSS-API proposal
  * Update from AT&T on their work
  * Detailed discussion of GSS-API proposal
  * Kerberos V5 update
  * Export issues

	John Linn started off by giving an overview of the GSS-API proposal 
he had written including some background.  Mike Merritt asked why so much
effort had gone into making the authentication mechanism distinct from the
communications mechanism.  John pointed out that a goal of the API was to
be independent of authentication mechanism as well as independent of protocol
tower used.  A number of other specifics of the proposal were discussed.

	Bill Griffeth and Mike Merritt presented an overview of some of the
work they have been doing on an authentication scheme for System V.  The
model they described utilizes a "connection server" on the client system and
a "port monitor" on the target system that cooperate to create an authenticated
connection between a pair of principals.  They indicated that more work was
required in the areas of delegation and mapping this model onto a connectionless
service.

	Some discussion ensued regarding authentication in general and Kerberos
in particular.  One issue raised had to do with time manipulation; i.e., system
clocks cannot be set backwards.

	John Kohl provided a status update on Kerberos V5.  (Remember, this is
as of March 28.)  At that point the encoding of certificates was done and were
in the process of being encoded with an ASN.1 compiler.  The internal design
documents were done and some coding was underway.  John indicated that the
project was resource constrained and that that was being worked.  He had no
schedule information to share.

	The question was posed as to how the various groups felt about the
API proposal.  Joe Pato of Apollo/HP indicated that from their point of view
authentication by itself was not really enough and that they were looking to
also provide some level of authorization, at least dealing with PAC's
(privilege attribute certificates?)  This would address group membership issues
as well as capabilities.  John Kohl felt that if the API could be implemented
he would like to see it included as part of the Kerberos V5 distribution.  
Athena has some sample code that could be modified to support the API and
Richard Pitkin said he would look into seeing if his group could help with that
effort.

	There was not time to discuss any export issues.  It was agreed that 
everyone should send comments on the proposal, including nits such as typos
and comments on wording, to John Linn ("linn@ultra.dec.com")  There was no 
proposed schedule for a next meeting although presumably another meeting is 
warrented.

                            [End of Minutes]


1,,
Summary-line: 27-Apr  3-5491.  27-Apr-1990 1415  #GSSAPI version C.2 in following message
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA15205; Fri, 27 Apr 90 13:18:13 EST
Received: from crl.dec.com by ATHENA.MIT.EDU with SMTP
	id AA13017; Fri, 27 Apr 90 14:18:09 EDT
Received: by crl.dec.com; id AA06748; Fri, 27 Apr 90 14:18:04 -0400
Received: by crltrx.crl.dec.com; id AA13395; Fri, 27 Apr 90 14:18:01 -0400
Received: by crltrx.crl.dec.com; id AA13389; Fri, 27 Apr 90 14:17:58 -0400
Received: by easynet.crl.dec.com; id AA23911; Fri, 27 Apr 90 10:11:21 -0400
Date: Fri, 27 Apr 90 10:11:20 -0400
Message-Id: <9004271411.AA23911@easynet.crl.dec.com>
From: linn@ultra.enet.dec.com (John Linn. 508-264-5491. DTN 293-5491.  27-Apr-1990 1415)
To: auth-api-ext@crl.dec.com
Cc: LINN@crl.dec.com
Subject: GSSAPI version C.2 in following message

*** EOOH ***
Date: Fri, 27 Apr 90 10:11:20 -0400
From: linn@ultra.enet.dec.com (John Linn. 508-264-5491. DTN 293-5491.  27-Apr-1990 1415)
To: auth-api-ext@crl.dec.com
Cc: LINN@crl.dec.com
Subject: GSSAPI version C.2 in following message

Under separate "cover", you'll be receiving an updated Generic Security Service
API draft document, designated version C.2.  The document is in PostScript
form, using Helvetica and Times Roman fonts in the interests of portability; if
this representation creates problems for you, let me know and I'll send a
pure ASCII version (though with different pagination and sans figures).

Relative to version C.1, this version addresses a number of areas
raised at the 28 March meeting and in subsequent comments I've received,
including the following:

- included per-message quality of protection parameter
- expanded clarification of goals, placement, rationale, and added
  some guidance to implementors
- new high-level caller-oriented scenario discussion
- discussion of relation between GSSAPI, PACs, and authorization (Appendix A)
- characterization of blocking vs. non-blocking calls
- renamed credential management calls to acquire_cred() and release_cred()
  to help underscore the fact that actual creation and deletion of credentials
  structures is likely to occur outside the scope of GSSAPI calls
- clarification on per-message replay detection and sequencing functions
- added Process_context_token() call so that tokens returned by
  Delete_sec_context() could be suitably processed
- changes to a few call parameters and return values
- general reorganization, added figures, added table

I'm circulating the draft at this time in the interests of stabilizing
agreement on GSSAPI concepts, and in recognition of the fact that I won't be in
a position to get back to the document before 14 May at the earliest. Some
supporting actions are pending and not included, but I don't think that they
interfere with convergence on the interface description at the level we've been
discussing and which is presented in this version C.2 document.  In particular,
ongoing work on C language bindings is not reflected here.  Per request, this
version adds a caller-oriented scenario overview; other, more detailed
scenarios discussions may emerge in subsequent versions or separate documents.

Comments solicited, to me or to the list.

Regards...

John Linn (linn@ultra.enet.dec.com)


1,answered,,
Summary-line:  7-Jun  3-5491.  07-Jun-1990 1905  #Status check re GSS-API and Athena Kerberos V5
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA02262; Thu, 7 Jun 90 19:08:44 EDT
Received: from decpa.pa.dec.com by ATHENA.MIT.EDU with SMTP
	id AA16301; Thu, 7 Jun 90 19:08:40 EDT
Received: by decpa.pa.dec.com; id AA03172; Thu, 7 Jun 90 16:08:35 -0700
Message-Id: <9006072308.AA03172@decpa.pa.dec.com>
Received: from ultra.enet; by decwrl.enet; Thu, 7 Jun 90 16:08:37 PDT
Date: Thu, 7 Jun 90 16:08:37 PDT
From: "John Linn. 508-264-5491. DTN 293-5491.  07-Jun-1990 1905" <linn@ultra.enet.dec.com>
To: jtkohl@ATHENA.MIT.EDU
Subject: Status check re GSS-API and Athena Kerberos V5

*** EOOH ***
Date: Thu, 7 Jun 90 16:08:37 PDT
From: "John Linn. 508-264-5491. DTN 293-5491.  07-Jun-1990 1905" <linn@ultra.enet.dec.com>
To: jtkohl@ATHENA.MIT.EDU
Subject: Status check re GSS-API and Athena Kerberos V5

John,

I don't think we've exchanged messages since version C.2 of the GSS-API spec,
and wanted to get a status check.  Where do you stand at this point with regard
to incorporation of the GSS-API as the Athena-recommended API to Kerberos V5,
per discussion at prior meetings? Subsequent to the last Cambridge meeting,
Bill Brown and Alex Chen have been involved in related detailed specification
and implementation activities; have you been aware of these, and do you think
they look to yield results which Athena would want to integrate?

Thanks, regards, ...

--jl

1,,
Summary-line:  8-Jun  John T Kohl                #Re: Status check re GSS-API and Athena Kerberos V5
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA09090; Fri, 8 Jun 90 16:10:42 EDT
Received: from LYCUS.MIT.EDU by ATHENA.MIT.EDU with SMTP
	id AA07471; Fri, 8 Jun 90 16:10:34 EDT
Received: by LYCUS.MIT.EDU (5.61/4.7) id AA09608; Fri, 8 Jun 90 16:10:28 -0400
Date: Fri, 8 Jun 90 16:10:28 -0400
From: John T Kohl <jtkohl@ATHENA.MIT.EDU>
Message-Id: <9006082010.AA09608@LYCUS.MIT.EDU>
To: "John Linn"	<linn@ultra.enet.dec.com>
In-Reply-To: John Linn. 508-264-5491. DTN 293-5491.  07-Jun-1990 1905's message of Thu, 7 Jun 90 16:08:37 PDT,
	<9006072308.AA03172@decpa.pa.dec.com>
Subject: Re: Status check re GSS-API and Athena Kerberos V5
X-Us-Snail: MIT Room E40-300, 1 Amherst St., Cambridge, MA 02139 USA

*** EOOH ***
Date: Fri, 8 Jun 90 16:10:28 -0400
From: John T Kohl <jtkohl@ATHENA.MIT.EDU>
To: "John Linn"	<linn@ultra.enet.dec.com>
In-Reply-To: John Linn. 508-264-5491. DTN 293-5491.  07-Jun-1990 1905's message of Thu, 7 Jun 90 16:08:37 PDT,
	<9006072308.AA03172@decpa.pa.dec.com>
Subject: Re: Status check re GSS-API and Athena Kerberos V5

> Date: Thu, 7 Jun 90 16:08:37 PDT
> From: "John Linn. 508-264-5491. DTN 293-5491.  07-Jun-1990 1905" <linn@ultra.enet.dec.com>

> John,

> I don't think we've exchanged messages since version C.2 of the GSS-API spec,
> and wanted to get a status check.  Where do you stand at this point with regard
> to incorporation of the GSS-API as the Athena-recommended API to Kerberos V5,
> per discussion at prior meetings?
We still want to incorporate this API, but were waiting on some C
bindings.

> Subsequent to the last Cambridge meeting,
> Bill Brown and Alex Chen have been involved in related detailed specification
> and implementation activities; have you been aware of these, 
No; I wish I'd known about them.

>and do you think
> they look to yield results which Athena would want to integrate?

Sounds likely that they would be useful to us.

I haven't gotten back to your reply to my comments, since I have once
again been busy.  These days I'm only spending about 1/4 time on
Kerberos stuff, and next week I'll be in Anaheim for the UseNIX
conference.

John

1,answered,,
Summary-line: 22-Jun  3-5491.  22-Jun-1990 0847  #Status of GSS-API work in progress
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA09110; Fri, 22 Jun 90 08:46:17 EDT
Received: from decpa.pa.dec.com by ATHENA.MIT.EDU with SMTP
	id AA05207; Fri, 22 Jun 90 08:46:13 EDT
Received: by decpa.pa.dec.com; id AA28866; Fri, 22 Jun 90 05:46:07 -0700
Message-Id: <9006221246.AA28866@decpa.pa.dec.com>
Received: from ultra.enet; by decwrl.enet; Fri, 22 Jun 90 05:46:08 PDT
Date: Fri, 22 Jun 90 05:46:08 PDT
From: "John Linn. 508-264-5491. DTN 293-5491.  22-Jun-1990 0847" <linn@ultra.enet.dec.com>
To: jtkohl@ATHENA.MIT.EDU
Subject: Status of GSS-API work in progress

*** EOOH ***
Date: Fri, 22 Jun 90 05:46:08 PDT
From: "John Linn. 508-264-5491. DTN 293-5491.  22-Jun-1990 0847" <linn@ultra.enet.dec.com>
To: jtkohl@ATHENA.MIT.EDU
Subject: Status of GSS-API work in progress

John,

As of a couple of weeks ago, you said that you hadn't heard much about GSS-API
refinement and implementation activities going on inside Digital, and would be
interested in more information with an eye towards possible use of results by
Athena.  Here's an update on some ongoing activities.

Alex Chen (CAGE::CHEN) has been working on a draft of concrete C bindings for
the GSS-API; this draft is currently under review.  

Alex has also completed an implementation of GSS-API on top of the Ultrix
version of Kerberos V4 and would be interested in follow-on work on V5
integration; the following is excerpted from his implementation description:

The way I have implemented GSSAPI to interface with Kerberos-V4-on-Ultrix
is to split GSSAPI into two layers of routines.  The higher layer routines,
included in GSS_CRED_MGMT.C, GSS_CNTXT.C and GSS_PER_MSG.C files, are
designed to provide the interface to the above applications.  The lower layer
routines, included in GSS_KRB_V4_DEC_CRED_MGMT.C, GSS_KRB_V4_DEC_CNTXT.C and
GSS_KRB_V4_DEC_PER_MSG.C files, obviously interface with the Kerberos V4
version on Ultrix.  As you can see also that the routines are grouped into
the way exactly that John Linn put them in his GSSAPI spec.  For instance,
GSS_CRED_MGMT.C contains routines managing credentials and they are
acquire_cred() and release_cred().

To draw a picture for that will be like this:

                +----------------------------------------------+
                |              GSSAPI applications             |
                +----------------------------------------------+
                  ||                   ||                   ||
                 \||/                 \||/                 \||/
                  \/                   \/                   \/
+---------------------------+------------------------+-------------------------+
|     GSS_CRED_MGMT.C       |       GSS_CNTXT.C      |      GSS_PER_MSG.C      |
+---------------------------+------------------------+-------------------------+
|GSS_KRB_V4_DEC_CRED_MGMT.C | GSS_KRB_V4_DEC_CNTXT.C | GSS_KRB_V4_DEC_PER_MSG.C|
+---------------------------+------------------------+-------------------------+
                  ||                   ||                   ||
                 \||/                 \||/                 \||/
                  \/                   \/                   \/
             +-------------------------------------------------+
             |           Kerberos V4 routines on Ultrix        |
             +-------------------------------------------------+


All these files, including 'C', header files and makefile, have been
archived.  You should be able to just copy the TAR file over and
unpack them with 'tar' utility on Ultrix.  The commands could be:

      $ dcp -i jfcl::/usr/users/alex/gssapi.tar ./gssapi.tar
      $ tar xvtf gssapi.tar

Once you unpack all the source files, run 'make' to create the GSSAPI 
library 'libgss.a'.  Then you are ready to modify your application
and link with GSSAPI and hopefully will run.

--jl

1,,
Summary-line:  9-Jul  John T Kohl                #[John Linn. 508-264-5491. DTN 293-5491.  24-Apr-1990 1035: RE: API comments]
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA07382; Mon, 9 Jul 90 15:52:15 EDT
Received: from crl.dec.com by ATHENA.MIT.EDU with SMTP
	id AA28601; Mon, 9 Jul 90 15:52:12 EDT
Received: by crl.dec.com; id AA07490; Mon, 9 Jul 90 15:52:10 -0400
Received: by crltrx.crl.dec.com; id AA16223; Mon, 9 Jul 90 15:52:07 -0400
Date: Mon, 9 Jul 90 15:52:07 -0400
From: jtkohl@crl.dec.com (John T Kohl)
Message-Id: <9007091952.AA16223@crltrx.crl.dec.com>
To: jtkohl@ATHENA.MIT.EDU
Subject: [John Linn. 508-264-5491. DTN 293-5491.  24-Apr-1990 1035: RE: API comments]
X-Us-Snail: MIT Room E40-300, 1 Amherst St., Cambridge, MA 02139 USA

*** EOOH ***
Date: Mon, 9 Jul 90 15:52:07 -0400
From: jtkohl@crl.dec.com (John T Kohl)
To: jtkohl@ATHENA.MIT.EDU
Subject: [John Linn. 508-264-5491. DTN 293-5491.  24-Apr-1990 1035: RE: API comments]



------- Forwarded Message

Date: Tue, 24 Apr 90 06:29:21 -0400
From: linn@ultra.enet.dec.com (John Linn. 508-264-5491. DTN 293-5491.  24-Apr-1990 1035)
To: jtkohl@CRL.enet
Cc: LINN
Subject: RE: API comments

>Sorry these are so late, I've been quite busy, as I am sure we all have
>been.  

How true.  Thanks.
 
>In general:
>I don't particularly care for some of your names for the parameters; I
>can send you my suggestions if you wish.

Alternate nominations accepted.  
 
>Some (most?) of the octet strings would more naturally be (void *) in C.

People in the DASS group are working on proposals for C bindings; I'll forward
your comments in this area to them.
 
>Sign & Unsign won't work with existing Kerberos v4 or v5 packet formats;
>the integrity-only checks don't provide a way to separate the integrity
>check info from the data.

True. Sign and Verify expect to operate in a scenario which expects the caller
to distinguish messages from per_msg_tokens, which is clearly divergent from
use of a defined packet format binding the two.  In principle (if an
application had a good reason for wanting to pack the bits in an idiosyncratic
way), would it be possible to implement a different interface into Kerberos
manipulating the data elements separately, using the basic mechanism but not
the wire format?

>Seal & Unseal, as a consequence, would require two mechanisms in v4/v5,
>to support both the KRB_SAFE and KRB_PRIV messages.

Within a single mechanism, would it be OK for the value of the conf_req_flag 
to drive whether a KRB_SAFE or KRB_PRIV message were generated?

>The error code NO_CONTEXT is appropriate for all of the calls except
>init_sec_context.

Not for the credential management calls, I don't think. Added to
Delete_sec_context().  Reviewing the situation, I think that NO_CONTEXT makes
sense for init_sec_context() and accept_sec_context(), but only on a successor
call following a RETRY_NEEDED sequence.  Did you have another scenario in mind
for accept_sec_context()?
 
>Estab_cred:
>There would seem to need to be 2 versions of this in the Kerberos world,
>since server keys are not stored in the same way that client tickets are
>stored.  Any good way to distinguish between the flavors in the API?

Given different implementation strategies, credential management is hard to
encompass wholly within a generic umbrella.  I've added more text in this area,
also renaming Estab_cred() to Acquire_cred() to underscore the possibility that
login or other process creation may cause credentials to exist, and that the
GSSAPI call may establish a handle to something already there rather than
creating it anew.
 
>any good reason why timedelta shouldn't be in seconds?

Done, by popular request.
 
>How do we specify a channel-binding in a generic way, taking into
>account the need for multiple address types, etc. even within a
>particular mechanism?

I'll see if I can add any clarification here.

--jl


------- End Forwarded Message

1,,
Summary-line:  9-Jul  John T Kohl                #Re: Status of GSS-API work in progress
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA07393; Mon, 9 Jul 90 15:53:17 EDT
Received: from LYCUS.MIT.EDU by ATHENA.MIT.EDU with SMTP
	id AA28639; Mon, 9 Jul 90 15:53:15 EDT
Received: by LYCUS.MIT.EDU (5.61/4.7) id AA01708; Mon, 9 Jul 90 15:53:12 -0400
Date: Mon, 9 Jul 90 15:53:12 -0400
From: John T Kohl <jtkohl@ATHENA.MIT.EDU>
Message-Id: <9007091953.AA01708@LYCUS.MIT.EDU>
To: linn@ultra.enet.dec.com
In-Reply-To: John Linn. 508-264-5491. DTN 293-5491.  22-Jun-1990 0847's message of Fri, 22 Jun 90 05:46:08 PDT,	<9006221246.AA28866@decpa.pa.dec.com>
Subject: Re: Status of GSS-API work in progress
X-Us-Snail: MIT Room E40-300, 1 Amherst St., Cambridge, MA 02139 USA

*** EOOH ***
Date: Mon, 9 Jul 90 15:53:12 -0400
From: John T Kohl <jtkohl@ATHENA.MIT.EDU>
To: linn@ultra.enet.dec.com
In-Reply-To: John Linn. 508-264-5491. DTN 293-5491.  22-Jun-1990 0847's message of Fri, 22 Jun 90 05:46:08 PDT,	<9006221246.AA28866@decpa.pa.dec.com>
Subject: Re: Status of GSS-API work in progress

thanks for the pointers.  I've been a bit too busy to deal with this at
the moment, and I'm going to be leaving on Friday for a 2-week trip.
I'll try to look at things again when I return in August.

John

1,,
Summary-line: 18-Dec  John Carr                  #DEC reply to gss comments
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA22362; Tue, 18 Dec 90 11:41:37 EST
Received: from ACHATES.MIT.EDU by ATHENA.MIT.EDU with SMTP
	id AA03716; Tue, 18 Dec 90 11:41:34 EST
Received: by Achates.MIT.EDU (5.61) id AA02131; Tue, 18 Dec 90 11:41:30 -0500
Message-Id: <9012181641.AA02131@Achates.MIT.EDU>
To: jtkohl@ATHENA.MIT.EDU
Subject: DEC reply to gss comments
Date: Tue, 18 Dec 90 11:41:29 EST
From: John Carr <jfc@ATHENA.MIT.EDU>

*** EOOH ***
To: jtkohl@ATHENA.MIT.EDU
Subject: DEC reply to gss comments
Date: Tue, 18 Dec 90 11:41:29 EST
From: John Carr <jfc@ATHENA.MIT.EDU>


------- Forwarded Message

Received: by E40-PO.MIT.EDU (5.45/4.7) id AA22354; Tue, 18 Dec 90 11:37:58 EST
Received: from decpa.pa.dec.com by ATHENA.MIT.EDU with SMTP
	id AA03638; Tue, 18 Dec 90 11:37:50 EST
Received: by decpa.pa.dec.com; id AA29838; Tue, 18 Dec 90 08:36:43 -0800
Message-Id: <9012181636.AA29838@decpa.pa.dec.com>
Received: from ultra.enet; by decwrl.enet; Tue, 18 Dec 90 08:37:03 PST
Date: Tue, 18 Dec 90 08:37:03 PST
From: "Morrie Gasser, LTN1-1/D07, DTN 226-6180  18-Dec-1990 1140"
<gasser@ultra.enet.dec.com>
To: jfc@ATHENA.MIT.EDU
Subject: RE: GSS API comments

John,

I'm sorry if we haven't gotten back to you on this yet.  We're here actively
putting together the latest C description of our GSS library, and should have
something to show you in a few weeks.

The large numbers of arguments have been a problem.  They are all necessary if
you want to use all the authentication services in the most flexible way, but
most users would be happy with a much more constrained set, so we are looking
at ways to simplify this for the majority of cases.  John Wray is the person
doing this design work (wray@ultra.enet.dec.com), so he can best discuss the
rationale with you.  Also, you will get the quickest answer if you send your
questions directly to John (copy me on your correspondence).

We are very hopeful that you will be able to incorporate the GSS API into
Kerberos V5, and make it part of the "official" Athena offering, so I'd like to
keep in touch on this issue to make sure our specification is acceptable to
you.

Morrie

------- End of Forwarded Message


1, answered,,
Summary-line:  2-Jan  26-6180  02-Jan-1991 0924  #1-week old question on GSS API
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA06411; Wed, 2 Jan 91 09:20:04 EST
Received: from decpa.pa.dec.com by MIT.EDU with SMTP
	id AA13212; Wed, 2 Jan 91 09:19:55 EST
Received: by decpa.pa.dec.com; id AA14829; Wed, 2 Jan 91 06:19:49 -0800
Message-Id: <9101021419.AA14829@decpa.pa.dec.com>
Received: from ultra.enet; by decwrl.enet; Wed, 2 Jan 91 06:19:50 PST
Date: Wed, 2 Jan 91 06:19:50 PST
From: "Morrie Gasser, LTN1-1/D07, DTN 226-6180  02-Jan-1991 0924" <gasser@ultra.enet.dec.com>
To: jtkohl@MIT.EDU
Subject: 1-week old question on GSS API

*** EOOH ***
Date: Wed, 2 Jan 91 06:19:50 PST
From: "Morrie Gasser, LTN1-1/D07, DTN 226-6180  02-Jan-1991 0924" <gasser@ultra.enet.dec.com>
To: jtkohl@MIT.EDU
Subject: 1-week old question on GSS API

Received: by easynet.crl.dec.com; id AA02984; Fri, 21 Dec 90 08:29:20 -0500
Message-Id: <9012211329.AA02984@easynet.crl.dec.com>
Received: from ultra.enet; by crl.enet; Fri, 21 Dec 90 08:32:34 EST
Date: Fri, 21 Dec 90 08:32:34 EST
From: "Morrie Gasser, LTN1-1/D07, DTN 226-6180  21-Dec-1990 0833" <gasser@ultra.enet.dec.com>
To: jtkohl@mit.edu
Subject: GSSAPI
 
As long as I have you on the line, have you guys decided yet whether you
definitely do or don't intend to incorporate the GSS API into V5?  I know we
still owe you the C bindings for our latest version, but I need to get a feel
for how high a priority I should place on writing that up.  I might be able to
cause people to jump through hoops to get it done, but to do that I need to 
understand the urgency from your perspective.
 
% ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ======
Received: by easynet.crl.dec.com; id AA12072; Mon, 24 Dec 90 09:54:57 -0500
From: MAILER-DAEMON (Mail Delivery Subsystem)
Subject: Returned mail: Cannot send message for 3 days
To: ultra::gasser


1,,
Summary-line:  3-Jan  John T Kohl                #Re: 1-week old question on GSS API
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA13256; Thu, 3 Jan 91 14:29:12 EST
Received: from LYCUS.MIT.EDU by MIT.EDU with SMTP
	id AA19002; Thu, 3 Jan 91 14:29:11 EST
Received: by lycus.MIT.EDU (5.61/4.7) id AA20855; Thu, 3 Jan 91 14:29:06 -0500
Date: Thu, 3 Jan 91 14:29:06 -0500
From: John T Kohl <jtkohl@MIT.EDU>
Message-Id: <9101031929.AA20855@lycus.MIT.EDU>
To: "Morrie Gasser" <gasser@ultra.enet.dec.com>
Cc: jis@MIT.EDU, jon@MIT.EDU
In-Reply-To: Morrie Gasser, LTN1-1/D07, DTN 226-6180  02-Jan-1991 0924's message of Wed, 2 Jan 91 06:19:50 PST,
	<9101021419.AA14829@decpa.pa.dec.com>
Subject: Re: 1-week old question on GSS API
X-Us-Snail: MIT Room E40-300, 1 Amherst St., Cambridge, MA 02139 USA

*** EOOH ***
Date: Thu, 3 Jan 91 14:29:06 -0500
From: John T Kohl <jtkohl@MIT.EDU>
To: "Morrie Gasser" <gasser@ultra.enet.dec.com>
Cc: jis@MIT.EDU, jon@MIT.EDU
In-Reply-To: Morrie Gasser, LTN1-1/D07, DTN 226-6180  02-Jan-1991 0924's message of Wed, 2 Jan 91 06:19:50 PST,
	<9101021419.AA14829@decpa.pa.dec.com>
Subject: Re: 1-week old question on GSS API

> Date: Wed, 2 Jan 91 06:19:50 PST
> From: "Morrie Gasser"

> As long as I have you on the line, have you guys decided yet whether you
> definitely do or don't intend to incorporate the GSS API into V5?  I know we
> still owe you the C bindings for our latest version, but I need to get a feel
> for how high a priority I should place on writing that up.  I might be able to
> cause people to jump through hoops to get it done, but to do that I need to 
> understand the urgency from your perspective.

We do want to include it, but we've stopped worrying about it at the
moment.  I expect we'll be ready for a wider beta-test by sometime in
mid-February; it would be nice to have it available by then.

I know Alex Chen and John Carr have been communicating about various
technical details of the C interface; you might ask Alex where they
think things stand.

John

1,,
Summary-line: 22-Oct  John T Kohl                #resend of message
Received: by crltrx.crl.dec.com; id AA28347; Mon, 22 Oct 90 16:20:38 -0400
Date: Mon, 22 Oct 90 16:20:38 -0400
From: jtkohl (John T Kohl)
Message-Id: <9010222020.AA28347@crltrx.crl.dec.com>
To: linn@zendia.enet, Gasser@ultra.enet
Subject: resend of message
X-Us-Snail: MIT Room E40-300, 1 Amherst St., Cambridge, MA 02139 USA

*** EOOH ***
Date: Mon, 22 Oct 90 16:20:38 -0400
From: jtkohl (John T Kohl)
To: linn@zendia.enet, Gasser@ultra.enet
Subject: resend of message

Here's the message I sent from Athena earlier; I am sending this copy
>from CRLTRX, so it should hopefully arrive sooner.

Date: Mon, 22 Oct 90 10:31:51 -0400
From: John T Kohl <jtkohl@ATHENA.MIT.EDU>
To: "John Linn"	<linn@zendia.enet.dec.com>
In-Reply-To: John Linn's message of Thu, 18 Oct 90 05:39:53 PDT,
	<9010181239.AA06703@decpa.pa.dec.com>
Subject: Re: Athena status re Kerberos V5 and GSSAPI?

> Date: Thu, 18 Oct 90 05:39:53 PDT
> From: "John Linn" <linn@zendia.enet.dec.com>

> What's Athena's current status regarding Kerberos V5's code release schedule
> and integration/use/packaging of GSSAPI with it?

We're currently in alpha test of V5 code; I am in the process of mapping
out a schedule to get V5 "out the door".  I have someone looking at the
GSS C code, and he'll be figuring out how best to integrate a V5
implementation.

> In terms of information from
> here, I saw Alex Chen's cover note to you early in September enclosing the
> Kerberos V4 code he developed over the summer, and presume that you saw the
> updated V-C.3 spec that I circulated later in the month.

Yes, we've gotten the C.3 draft here, and I have someone looking at it.

>  FYI, a detailed C
> bindings document to go along with V-C.3 is in preparation and will be
> forthcoming.  

We are looking forward to it.



1, forwarded,,
Summary-line: 23-Oct  3-5055,  23-Oct-1990 0804  #RE: resend of message 
Received: by crltrx.crl.dec.com; id AA01945; Tue, 23 Oct 90 08:06:57 -0400
Received: by easynet.crl.dec.com; id AA18428; Tue, 23 Oct 90 08:05:37 -0400
Message-Id: <9010231205.AA18428@easynet.crl.dec.com>
Received: from ultra.enet; by crl.enet; Tue, 23 Oct 90 08:05:40 EDT
Date: Tue, 23 Oct 90 08:05:40 EDT
From: "Morrie Gasser, 508-264-5055, DTN 293-5055,  23-Oct-1990 0804" <gasser@ultra.enet.dec.com>
To: jtkohl
Subject: RE: resend of message 

*** EOOH ***
Date: Tue, 23 Oct 90 08:05:40 EDT
From: "Morrie Gasser, 508-264-5055, DTN 293-5055,  23-Oct-1990 0804" <gasser@ultra.enet.dec.com>
To: jtkohl
Subject: RE: resend of message 

Thanks, John.  I am told that we will have the C bindings for GSSAPI C.3
in about two weeks.  Do I take your message to imply that there is 
a possibility that, when V5 gets "out the door", it will come with a GSSAPI
interface?  If that's a distinct possibility, then we'll do all we can to help
expedite this.  I would particularly like to see the GSSAPI interface on
Kerberos if OSF decides to offer Kerberos V5 with DCE.


1, forwarded,,
Summary-line: 20-Nov  26-6180  20-Nov-1990 0956  #C spec for GSSAPI
Received: by crltrx.crl.dec.com; id AA03950; Tue, 20 Nov 90 10:01:14 -0500
Received: by easynet.crl.dec.com; id AA05507; Tue, 20 Nov 90 09:59:56 -0500
Message-Id: <9011201459.AA05507@easynet.crl.dec.com>
Received: from ultra.enet; by crl.enet; Tue, 20 Nov 90 10:00:03 EST
Date: Tue, 20 Nov 90 10:00:03 EST
From: "Morrie Gasser, LTN1-1/D07, DTN 226-6180  20-Nov-1990 0956" <gasser@ultra.enet.dec.com>
To: jtkohl
Subject: C spec for GSSAPI

*** EOOH ***
Date: Tue, 20 Nov 90 10:00:03 EST
From: "Morrie Gasser, LTN1-1/D07, DTN 226-6180  20-Nov-1990 0956" <gasser@ultra.enet.dec.com>
To: jtkohl
Subject: C spec for GSSAPI

John,   

About 3 weeks ago I mentioned that a C spec for the GSSAPI would be coming to
you.  We've had some delays (resource constraints) so it's not coming as
quickly as I had hoped.  To help me judge the priority of preparing this spec
(since we will have to trade this off against something else), can you tell me
what's your time frame for implementing it?  If you know you can't possibly get
to it for a while, I'd rather push it out a bit.  If you say you're eagerly
ready to get coding on it right away, I'll move it up to high priority.

Morrie


1, answered,,
Summary-line:  3-Jan  26-6180  03-Jan-1991 1500  #RE: Re: 1-week old question on GSS API 
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA13432; Thu, 3 Jan 91 14:57:18 EST
Received: from crl.dec.com by MIT.EDU with SMTP
	id AA19196; Thu, 3 Jan 91 14:57:17 EST
Received: by crl.dec.com; id AA22789; Thu, 3 Jan 91 14:57:11 -0500
Received: by easynet.crl.dec.com; id AA09688; Thu, 3 Jan 91 14:56:02 -0500
Message-Id: <9101031956.AA09688@easynet.crl.dec.com>
Received: from ultra.enet; by crl.enet; Thu, 3 Jan 91 14:56:11 EST
Date: Thu, 3 Jan 91 14:56:11 EST
From: "Morrie Gasser, LTN1-1/D07, DTN 226-6180  03-Jan-1991 1500" <gasser@ultra.enet.dec.com>
To: jtkohl@MIT.EDU
Subject: RE: Re: 1-week old question on GSS API 

*** EOOH ***
Date: Thu, 3 Jan 91 14:56:11 EST
From: "Morrie Gasser, LTN1-1/D07, DTN 226-6180  03-Jan-1991 1500" <gasser@ultra.enet.dec.com>
To: jtkohl@MIT.EDU
Subject: RE: Re: 1-week old question on GSS API 

> I know Alex Chen and John Carr have been communicating about various
> technical details of the C interface; you might ask Alex where they
> think things stand.

Thanks.  Alex Chen is no longer working on this, but several other people are
in his place.  Would it be better for me to contact John Carr directly?  I sent
him a message on Dec. 18 but got no response.  I'm not sure who's responsible
for making decisions on what gets done at what time.  The last I saw was a
question from John Carr on 27 November asking a few questions about Alex's
spec.

1,,
Summary-line:  3-Jan  John T Kohl                #Re: Re: 1-week old question on GSS API 
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA13542; Thu, 3 Jan 91 15:21:10 EST
Received: from LYCUS.MIT.EDU by MIT.EDU with SMTP
	id AA19361; Thu, 3 Jan 91 15:21:09 EST
Received: by lycus.MIT.EDU (5.61/4.7) id AA20909; Thu, 3 Jan 91 15:21:03 -0500
Date: Thu, 3 Jan 91 15:21:03 -0500
From: John T Kohl <jtkohl@MIT.EDU>
Message-Id: <9101032021.AA20909@lycus.MIT.EDU>
To: "Morrie Gasser" <gasser@ultra.enet.dec.com>
In-Reply-To: Morrie Gasser's message of Thu, 3 Jan 91 14:56:11 EST,
	<9101031956.AA09688@easynet.crl.dec.com>
Subject: Re: Re: 1-week old question on GSS API 
X-Us-Snail: MIT Room E40-300, 1 Amherst St., Cambridge, MA 02139 USA

*** EOOH ***
Date: Thu, 3 Jan 91 15:21:03 -0500
From: John T Kohl <jtkohl@MIT.EDU>
To: "Morrie Gasser" <gasser@ultra.enet.dec.com>
In-Reply-To: Morrie Gasser's message of Thu, 3 Jan 91 14:56:11 EST,
	<9101031956.AA09688@easynet.crl.dec.com>
Subject: Re: Re: 1-week old question on GSS API 

Feel free to contact John directly; he's working with the code.  Jeff
Schiller and I are working on figuring out exactly what we want to put
into the release.

John

1,,
Summary-line:  4-Jan  26-6180  04-Jan-1991 1249  #Revised GSS API
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA19512; Fri, 4 Jan 91 17:56:49 EST
Received: from decpa.pa.dec.com by ATHENA.MIT.EDU with SMTP
	id AA08087; Fri, 4 Jan 91 17:56:39 EST
Received: by decpa.pa.dec.com; id AA02249; Fri, 4 Jan 91 14:55:48 -0800
Message-Id: <9101042255.AA02249@decpa.pa.dec.com>
Received: from ultra.enet; by decwrl.enet; Fri, 4 Jan 91 14:56:04 PST
Date: Fri, 4 Jan 91 14:56:04 PST
From: "Morrie Gasser, LTN1-1/D07, DTN 226-6180  04-Jan-1991 1249" <gasser@ultra.enet.dec.com>
To: jfc@ATHENA.MIT.EDU
Subject: Revised GSS API

*** EOOH ***
Date: Fri, 4 Jan 91 14:56:04 PST
From: "Morrie Gasser, LTN1-1/D07, DTN 226-6180  04-Jan-1991 1249" <gasser@ultra.enet.dec.com>
To: jfc@ATHENA.MIT.EDU
Subject: Revised GSS API

John,

I just want to touch base on GSS API status as it's been a while.  We are very
close to issuing a document that describes the C spec for the GSS API.  This
interface is probably fairly different from the one that you got from Alex Chen
some months ago, and we would appreciate your comments.  Can I send you a
postscript version of the document (it's fairly long)?  If not, what's your
U.S. mail address?

Morrie

1,,
Summary-line:  7-Jan  John Williams              #Generic security interface meeting
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA27364; Mon, 7 Jan 91 11:52:12 EST
Received: from decvax.dec.com by MIT.EDU with SMTP
	id AA01932; Mon, 7 Jan 91 11:51:36 EST
Received: by decvax.dec.com (5.57/decvax-27Nov90)
	id AA07477; Mon, 7 Jan 91 11:47:15 -0500
Received: by abyss.zk3.dec.com (5.57/ueg-15Nov90)
	id AA00538; Mon, 7 Jan 91 11:22:12 -0500
Date: Mon, 7 Jan 91 11:22:12 -0500
From: williams@decvax.dec.com (John Williams)
Message-Id: <9101071622.AA00538@abyss.zk3.dec.com>
To: COVERT@COVERT.enet.dec.com, KAUFMAN@ERLANG.enet.dec.com,
        SCHIMPF@TOOK.enet.dec.com, GASSER@ULTRA.enet.dec.com,
        KAHN@ULTRA.enet.dec.com, MCDERMOTT@ULTRA.enet.dec.com,
        MODEEN@ULTRA.enet.dec.com, WRAY@ULTRA.enet.dec.com,
        LINN@ZENDIA.enet.dec.com, bbrown@abyss.zk3.dec.com,
        dlong@abyss.zk3.dec.com, dws@abyss.zk3.dec.com, fran@abyss.zk3.dec.com,
        hu@abyss.zk3.dec.com, jtkohl@MIT.EDU, sastry@abyss.zk3.dec.com,
        scott@abyss.zk3.dec.com
Subject: Generic security interface meeting

*** EOOH ***
Date: Mon, 7 Jan 91 11:22:12 -0500
From: williams@decvax.dec.com (John Williams)
To: COVERT@COVERT.enet.dec.com, KAUFMAN@ERLANG.enet.dec.com,
        SCHIMPF@TOOK.enet.dec.com, GASSER@ULTRA.enet.dec.com,
        KAHN@ULTRA.enet.dec.com, MCDERMOTT@ULTRA.enet.dec.com,
        MODEEN@ULTRA.enet.dec.com, WRAY@ULTRA.enet.dec.com,
        LINN@ZENDIA.enet.dec.com, bbrown@abyss.zk3.dec.com,
        dlong@abyss.zk3.dec.com, dws@abyss.zk3.dec.com, fran@abyss.zk3.dec.com,
        hu@abyss.zk3.dec.com, jtkohl@MIT.EDU, sastry@abyss.zk3.dec.com,
        scott@abyss.zk3.dec.com
Subject: Generic security interface meeting

The goal of this meeting is to get started on the definition of a
generic security interface for authentication which layers login, su
passwd, dxsession, Xprompter, dlogin, and rtools from the specific
security policy or mechnism local or distributed. 

The hercules security interface planning meeting will be held on 
Friday 11-4 at ZK3 in the Archimedes cr. The agenda will be as follows:


11-12	Introduce/Define the Requirements of the security layering
	for the hercules(bronze) OSF product. I, John Williams, will
	present food for thought. Any other possibilities/requirements
	should be presented.

12-1    Lunch

1-4	Discuss/Review the possible interface designs. 
	Issues:
		Rtool interfaces and how they differ from login.

		Changing of passwords generic mechanism.

		Administration/configuration constraints/issues
		DAS/OSFDCE interoperability.

		Kernel caching of tickets/certificates

		Generic Authorization. To be or not to be in bronze.

		Smart Card futures.

	Establish what the tasks are to complete this project.

	Establish who will be doing what when.
						
Attendees/invitees please forward when appropriate. Note there is enough
room for 8 extras.

		  John Williams		abyss::williams
		  David Long		flume::dlong
		  Larry Scott		abyss::scott
		  K.V. Sastry		abyss::sastry
		  Irene Hu		abyss::hu
		  Bill Brown		abyss::bbrown
		  David Summers		abyss::dws
		  Fran Fadden		krisis::fran
		  John Covert		COVERT::COVERT
		  John Wray		ULTRA::WRAY
		  John Linn		ZENDIA::LINN
		  Charles Kaufman	ERLANG::KAUFMAN
		  Brian Schimpf		TOOK::SCHIMPF
		  Ray Modeen		ULTRA::MODEEN
		  Morrie Gasser 	ULTRA::GASSER
		  Cliff Kahn		ULTRA::KAHN
		  Ellen Mcdermott	ULTRA::MCDERMOTT
		  John Kohl		mit.edu
		  
		  

		

1, answered,,
Summary-line:  9-Oct  s.Russell@newcastle.ac.uk  #OSF API to Kerberos
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA14637; Tue, 9 Oct 90 12:30:01 EDT
Received: from sun2.nsfnet-relay.ac.uk by ATHENA.MIT.EDU with SMTP
	id AA16385; Tue, 9 Oct 90 12:25:57 EDT
Received: from vax.nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk 
          with SMTP inbound id <5176-12@sun2.nsfnet-relay.ac.uk>;
          Tue, 9 Oct 1990 17:14:30 +0100
Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet 
          with NIFTP id aa11155; 9 Oct 90 16:09 BST
Received: from [+JANET.000001501500.ncl.mts.ftp.mail] by uk.ac.newcastle;
          Tue, 9 Oct 90 17:10:38 +0100
Date: Tue, 09 Oct 90 17:10:35 +0100
From: Denis.Russell@newcastle.ac.uk
Subject: OSF API to Kerberos
To: krb-protocol@ATHENA.MIT.EDU, kerberos@ATHENA.MIT.EDU
Message-Id: <emu-ct08.1990.1009.171036.cl04@uk.ac.ncl.mts>

*** EOOH ***
Date: Tue, 09 Oct 90 17:10:35 +0100
From: Denis.Russell@newcastle.ac.uk
Subject: OSF API to Kerberos
To: krb-protocol@ATHENA.MIT.EDU, kerberos@ATHENA.MIT.EDU

     I  understand  that  the  OSF  is developing an Application
Program Interface to Kerberos so that in the  fullness  of  time
kerberos  could  be  replaced by a suitable alternative service.
Can anyone point me to some  more  specific  information  and/or
contacts on this?
 
             Denis
 
Denis Russell           JANET:     Denis.Russell@uk.ac.newcastle
Computing Laboratory    Internet:  Denis.Russell@newcastle.ac.uk
The University
Claremont Road          Tel:   (+44) 91 222 8243
Newcastle upon Tyne     Fax:   (+44) 91 222 8232
       NE1 7RU          Telex: 53 65 4  UNINEW G
ENGLAND

1,,
Summary-line: 18-Jan  John T Kohl                #Re: OSF API to Kerberos
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA03459; Fri, 18 Jan 91 16:10:28 EST
Received: from LYCUS.MIT.EDU by MIT.EDU with SMTP
	id AA02713; Fri, 18 Jan 91 16:10:20 EST
Received: by lycus.MIT.EDU (5.61/4.7) id AA00437; Fri, 18 Jan 91 16:10:16 -0500
Date: Fri, 18 Jan 91 16:10:16 -0500
From: John T Kohl <jtkohl@MIT.EDU>
Message-Id: <9101182110.AA00437@lycus.MIT.EDU>
To: Denis.Russell@newcastle.ac.uk
In-Reply-To: Denis.Russell@newcastle.ac.uk's message of Tue, 09 Oct 90 17:10:35 +0100,
	<emu-ct08.1990.1009.171036.cl04@uk.ac.ncl.mts>
Subject: Re: OSF API to Kerberos
X-Us-Snail: MIT Room E40-300, 1 Amherst St., Cambridge, MA 02139 USA

*** EOOH ***
Date: Fri, 18 Jan 91 16:10:16 -0500
From: John T Kohl <jtkohl@MIT.EDU>
To: Denis.Russell@newcastle.ac.uk
In-Reply-To: Denis.Russell@newcastle.ac.uk's message of Tue, 09 Oct 90 17:10:35 +0100,
	<emu-ct08.1990.1009.171036.cl04@uk.ac.ncl.mts>
Subject: Re: OSF API to Kerberos

It's been a long while since this has been in my mailbox, but the best
contact I know is John Linn <linn@ultra.enet.dec.com>.

I am not aware of any OSF efforts.  John Linn gathered some DEC, MIT,
Apollo, and AT&T folk together early last year for some discussions,
which led to his current work.

John

1,,
Summary-line: 21-Jan  s.Russell@newcastle.ac.uk  #Re: OSF API to Kerberos
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA10805; Mon, 21 Jan 91 04:35:56 EST
Received: from sun2.nsfnet-relay.ac.uk by MIT.EDU with SMTP
	id AA10279; Mon, 21 Jan 91 04:35:51 EST
Received: from vax.nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk 
          with SMTP inbound id <2308-19@sun2.nsfnet-relay.ac.uk>;
          Mon, 21 Jan 1991 09:33:59 +0000
Received: from sun2.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet 
          with NIFTP id aa02263; 21 Jan 91 9:24 GMT
Received: from uk.ac.ncl.mts by uk.ac.newcastle; Mon, 21 Jan 91 09:29:26 GMT
Date: Mon, 21 Jan 91 09:27:57 GMT
From: Denis.Russell@newcastle.ac.uk
Subject: Re: OSF API to Kerberos
To: John T Kohl <jtkohl@MIT.EDU>
Message-Id: <emu-ov07.1991.0121.092758.cl04@uk.ac.ncl.mts>
In-Reply-To: <9101182110.AA00437@lycus.MIT.EDU>

*** EOOH ***
Date: Mon, 21 Jan 91 09:27:57 GMT
From: Denis.Russell@newcastle.ac.uk
Subject: Re: OSF API to Kerberos
To: John T Kohl <jtkohl@MIT.EDU>
In-Reply-To: <9101182110.AA00437@lycus.MIT.EDU>

Re:
 
> It's been a long while since this has been in my mailbox, but the best
> contact I know is John Linn <linn@ultra.enet.dec.com>.
>
> I am not aware of any OSF efforts.  John Linn gathered some DEC, MIT,
> Apollo, and AT&T folk together early last year for some discussions,
> which led to his current work.
>
> John
 
Many thanks for the info.  I've contacted John and got a copy of
his  paper.   I've  also been pointed to some work that has been
done in the OSF.  Thanks for reminding me - I must  try  to  get
more extensive information about it.
 
          Denis.

1, answered, edited, filed,,
Summary-line: 31-Jan  26-6180  31-Jan-1991 0819  #C bindings for GSS API
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA05937; Thu, 31 Jan 91 08:23:20 EST
Received: from decpa.pa.dec.com by ATHENA.MIT.EDU with SMTP
	id AA25003; Thu, 31 Jan 91 08:21:57 EST
Received: by decpa.pa.dec.com; id AA01471; Thu, 31 Jan 91 05:15:25 -0800
Message-Id: <9101311315.AA01471@decpa.pa.dec.com>
Received: from ultra.enet; by decwrl.enet; Thu, 31 Jan 91 05:15:31 PST
Date: Thu, 31 Jan 91 05:15:31 PST
From: "Morrie Gasser, LTN1-1/D07, DTN 226-6180  31-Jan-1991 0819" <gasser@ultra.enet.dec.com>
To: jfc@ATHENA.MIT.EDU
Subject: C bindings for GSS API

*** EOOH ***
Date: Thu, 31 Jan 91 05:15:31 PST
From: "Morrie Gasser, LTN1-1/D07, DTN 226-6180  31-Jan-1991 0819" <gasser@ultra.enet.dec.com>
To: jfc@ATHENA.MIT.EDU
Subject: C bindings for GSS API

At last, here is the postscript documentation of C bindings for the GSS API. 
This is just a draft, so it might have some rough edges.  Once you take a look
at it, let me know what you think your implementation plans might be to put it
on top of Kerberos V5.  

< snip snip >

1,,
Summary-line: 11-Mar  Percy Tzelnic              #Meeting notes - Athena/Kerberos - DEC/Sphinx;  3/5/91 
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA04767; Mon, 11 Mar 91 22:14:43 EST
Received: from enet-gw.pa.dec.com by ATHENA.MIT.EDU with SMTP
	id AA02027; Mon, 11 Mar 91 22:14:33 EST
Received: by enet-gw.pa.dec.com; id AA09678; Mon, 11 Mar 91 19:14:19 -0800
Message-Id: <9103120314.AA09678@enet-gw.pa.dec.com>
Received: from pmaxpt.enet; by decwrl.enet; Mon, 11 Mar 91 19:14:23 PST
Date: Mon, 11 Mar 91 19:14:23 PST
From: Percy Tzelnic <tzelnic@pmaxpt.enet.dec.com>
To: jis@ATHENA.MIT.EDU, "jtkohl@athena.mit.edu"@Pa.dec.com,
        "jfc@athena.mit.edu"@Pa.dec.com, "tytso@athena.mit.edu"@Pa.dec.com,
        kahn@zendia.enet.dec.com, linn@zendia.enet.dec.com,
        wray@ultra.enet.dec.com, kannan@sejour.enet.dec.com,
        tzelnic@Pa.dec.com
Subject: Meeting notes - Athena/Kerberos - DEC/Sphinx;  3/5/91 

*** EOOH ***
Date: Mon, 11 Mar 91 19:14:23 PST
From: Percy Tzelnic <tzelnic@pmaxpt.enet.dec.com>
To: jis@ATHENA.MIT.EDU, "jtkohl@athena.mit.edu"@Pa.dec.com,
        "jfc@athena.mit.edu"@Pa.dec.com, "tytso@athena.mit.edu"@Pa.dec.com,
        kahn@zendia.enet.dec.com, linn@zendia.enet.dec.com,
        wray@ultra.enet.dec.com, kannan@sejour.enet.dec.com,
        tzelnic@Pa.dec.com
Subject: Meeting notes - Athena/Kerberos - DEC/Sphinx;  3/5/91 

Cc: ultra::lipner, ultra::modeen, erlang::patel, tl::lauck, mailto::frampton,
	kibitz::kaufman, nac::tardo, erlang::wilde, smurf::ferson,
	lassie::lawler
 
Participants: 	
------------
 DEC - Kannan Alagappan, Cliff Kahn, John Linn, Percy Tzelnic, John Wray
 MIT - John Kohl, John Carr, Jeff Schiller, Ted T'so
 
Meeting goals: 
-------------
 1. Agree on a common GSSAPI (resolve all possible issues, 
    prepare an action plan, including a common statement); 
 2. Explore joint implementation work with MIT of the GSSAPI over 
    Kerberos;
 3. Explore joint work with MIT on the Kerberos/SPX 
    interoperability. 
 
Agenda (proposed):
-----------------
 1. Opening remarks (goals, agenda, etc.)
 2. John Linn's brief tour through specific areas of GSSAPI C.3 and 
    John Wray's C bindings to clarify goals, problems and solutions 
    that may not be obvious...
 3. Discussion; action items, closure of the GSSAPI topic. 
 4. Kannan Alagappan's brief discussion of Kerberos/SPX 
    interoperability goals.
 5. Closure and summary.
 
Brief summary:
-------------
 In four hours, we managed to cover the first three topics on the 
 agenda. Item 3 has taken most of the time; for lack of time, we didn't reach 
 complete closure. However, from conversations held during and after the 
 meeting, it is clear that both the Athena and the DEC team are very
 interested to work together, not only to achieve consensus on the GSSAPI,
 and thus achieve application portability, but also to explore full 
 interoperability betwenn Kerberos and Sphinx.
 
 The discussion of item 3 covered essentially two areas: storage 
 allocation within the GSSAPI, and naming. Consensus was reached on 
 the first area, and it consists of the following elements:
 - the C bindings will use a structure based approach; simple objects (i.e., 
   printable names, tokens, message data, channel bindings) are represented as 
   buffer structures; complex objects (credentials, contexts) are opaque, 
   represented by name types such as gss_credential_handle_t and
   gss_context_handle_t;
 - output variables will be malloc-ed and GSS will supply free routines that  
   call mechanism specific functions;
 - identify credentials and context handles as confidential;  [Given our
   agreement that each thing returned would be a fixed-size datum,
   possibly a pointer to the real data, it follows that we can rule that
   what is returned is *not* confidential.  We didn't say this in the
   meeting - Cliff Kahn's note] 
 - Jeff Schiller suggested the spec also be explicit about which returned items
   the caller was free to bash and which the caller was not free to bash. 
   Cliff Kahn added that the spec needs to be explicit about how 
   long a returned item stays around.  For example, we discussed flagging 
   an error if certain things were not freed by the time a security 
   context went away. 
 
 Other points of agreement:  There was consensus that a mechanism
 implementor's guide would be helpful. It was observed that
 channel bindings' values must be byte-order independent, and that
 this should be added to the spec. 
 
 The naming discussion visited a large number of ratholes. Without going into
 any details, the argument that seemed to carry quite a bit of weight was that 
 GSS needs a canonical representation for names. Since there is none widely 
 accepted for names as printable strings, the XOM binary representation (as 
 chosen in the DECdas C bindings) would make sense - as the only one that is 
 also a standard (or on the way to becoming one.)
 
Action items: 
------------
 1. Cliff Kahn needs to verify the feasibility of incorporating in the product
    schedule the consensus reached concerning the storage allocation issues.
 2. Naming will be  revisited,  in order to reach closure. We're meeting again 
    on Tuesday, 3/26/91 (9:30-12:30, CR Mark Twain, LKG1-2/J16.)
 

1,,
Summary-line: 22-Mar  6-6588.  22-Mar-1991 1002  #Background on GSSAPI naming approach
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA12307; Fri, 22 Mar 91 10:38:16 EST
Received: from enet-gw.pa.dec.com by ATHENA.MIT.EDU with SMTP
	id AA14963; Fri, 22 Mar 91 10:38:08 EST
Received: by enet-gw.pa.dec.com; id AA12868; Fri, 22 Mar 91 07:37:17 -0800
Message-Id: <9103221537.AA12868@enet-gw.pa.dec.com>
Received: from zendia.enet; by decwrl.enet; Fri, 22 Mar 91 07:37:45 PST
Date: Fri, 22 Mar 91 07:37:45 PST
From: "John Linn. 508.486.6588. DTN 226-6588.  22-Mar-1991 1002" <linn@zendia.enet.dec.com>
To: jis@mit.edu, "jtkohl@athena.mit.edu"@Pa.dec.com,
        "jfc@athena.mit.edu"@Pa.dec.com, "tytso@athena.mit.edu"@Pa.dec.com,
        kahn@Pa.dec.com, wray@ultra.enet.dec.com, kannan@sejour.enet.dec.com,
        tzelnic@pmaxpt.enet.dec.com
Subject: Background on GSSAPI naming approach

*** EOOH ***
Date: Fri, 22 Mar 91 07:37:45 PST
From: "John Linn. 508.486.6588. DTN 226-6588.  22-Mar-1991 1002" <linn@zendia.enet.dec.com>
To: jis@mit.edu, "jtkohl@athena.mit.edu"@Pa.dec.com,
        "jfc@athena.mit.edu"@Pa.dec.com, "tytso@athena.mit.edu"@Pa.dec.com,
        kahn@Pa.dec.com, wray@ultra.enet.dec.com, kannan@sejour.enet.dec.com,
        tzelnic@pmaxpt.enet.dec.com
Subject: Background on GSSAPI naming approach

GSSAPI NAMING RATIONALE

The purpose of this note is to illuminate some of the rationale and assumptions
behind the name manipulation functions incorporated in GSSAPI as of version
C.3.  The basic goal is to support portability across naming environments for a
range of applications, emphasizing features supportive of authorization and
audit capabilities which are likely to be of interest to the same callers
wishing to make use of GSSAPI-provided authentication services. The
applications targeted are those which have no intrinsic need to examine the
internals of encoded names, but which can be portable given availability of
functions to accept, display, and perform comparisons among those names.  

We believe that parsing and conversion of name representations is becoming, and
will continue over time to become, more a matter to be buried in standard
libraries and APIs than something which must be separately hand-coded into
individual applications.  As this evolution proceeds, it is likely that GSSAPI
implementations will evolve to supporting name manipulation functions through
invocation of naming-oriented library primitives.  Support within the GSSAPI
rubric is intended as a means to permit caller portability across mechanisms
and their associated naming conventions in advance of comprehensive and
pervasively available naming support libraries.  

Naming representations are not presumed to map 1:1 with authentication
mechanism types, but rather are typed separately from mechanisms.  It is
entirely possible (and useful) for a given mechanism to accomodate more than
one name type, and for the same name type to be accomodated by more than one
mechanism. 

In the version C.2 GSSAPI, names were wholly opaque OCTET STRINGs,  whose
internal structure was implicitly assumed to be variable, defined by different
underlying mechanisms.  The  recognized fact that different mechanisms will
expect and emit different types of names  (e.g., Kerberos' native form for a
Kerberos mechanism and X.500 for SPX) could be a significant  stumbling block
in the way of satisfying the GSSAPI goal of application  portability across
underlying mechanisms.  Tagging of names with types (represented by OBJECT
IDENTIFIERs) helps the  situation.  This makes it possible for an application
receiving a name from the GSSAPI to know whether it is equipped to perform any
processing  on the internals of that name, without risking aliasing problems
resulting from misinterpreting a name of one type as a name of another type. 
In the other direction, it allows GSSAPI routines to recognize whether input
names can be accomodated in conjunction with underlying mechanisms in use, and
to reject unprocessable naming forms.  

The GSS_Compare_name() call takes an additional step towards portability of
applications across naming environments, for those applications which can be
independent of naming structure internals.  GSS_Compare_name() performs a
simple comparison for the case of names of the same type, yielding one of three
possible results: equal, unequal, or incomparable. Optionally,
GSS_Compare_name() can compare names of different types if a GSSAPI
implementation is capable of performing a translation between those types. 

GSS_Import_name() provides a service to allow a GSSAPI caller to translate a
printable name representation (whose syntax is a local matter) into a
normalized, typed form suitable for processing by other GSSAPI routines.  For
the C language environment, we have elected to employ the emerging standard
X/Open Directory Services API (XDS API) format, in the interests of making
GSSAPI name representations compatible with probable name service references.
When a name represented in this internal form is no longer required, it is
deallocated with GSS_Release_name(). The GSS_Display_name() call accomodates
the need for callers to output names in a local, user-readable form.

--jl

1, answered, edited, filed,,
Summary-line: 25-Mar  26-6106  25-Mar-1991 1321  #Revised GSSAPI spec
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA25326; Mon, 25 Mar 91 14:08:17 EST
Received: from enet-gw.pa.dec.com by ATHENA.MIT.EDU with SMTP
	id AA17381; Mon, 25 Mar 91 14:07:16 EST
Received: by enet-gw.pa.dec.com; id AA15288; Mon, 25 Mar 91 10:59:24 -0800
Message-Id: <9103251859.AA15288@enet-gw.pa.dec.com>
Received: from ultra.enet; by decwrl.enet; Mon, 25 Mar 91 10:59:45 PST
Date: Mon, 25 Mar 91 10:59:45 PST
From: "John Wray, Secure Systems Development, DTN 226-6106  25-Mar-1991 1321" <wray@ultra.enet.dec.com>
To: mail11:;@enet-gw.pa.dec.com@enet-gw.pa.dec.com (@gssapi)
Subject: Revised GSSAPI spec

*** EOOH ***
Date: Mon, 25 Mar 91 10:59:45 PST
From: "John Wray, Secure Systems Development, DTN 226-6106  25-Mar-1991 1321" <wray@ultra.enet.dec.com>
To: mail11:;@enet-gw.pa.dec.com@enet-gw.pa.dec.com (@gssapi)
Subject: Revised GSSAPI spec

This is the latest GSSAPI specification (in PostScript, after the form-feed),
revised in accordance with the agreements from our last meeting.  Changes are:

i)	Definition and use of the gss_buffer_t datatype for passing "flat" data
	between the GSSAPI layer and the application.  Storage for gss_buffer_t
	data returned by the GSSAPI to the application will be allocated by the
	GSSAPI layer (or the underlying mechanism), and a GSSAPI procedure
	"gss_release_buffer" is defined to deallocate this storage.

ii)	Credential and context handles are identified by opaque data types
	gss_cred_id_t and gss_ctx_id_t.  Definition of these types is the
	responsibility of the GSSAPI implementor.  The XXX_id_t types should
	contain no sensitive data; They are merely handles by which the
	application may refer to object controlled by the underlying mechanism.
	The underlying objects are not directly accessible to the application.

iii)	A discussion of the X/Open object management data structures is
	included in section 4.  This section gives an overview of the XOM
	representation; The X/Open specifications provide the detailed
	definitions.

iv)	I have added some extra explicit "this parameter is read-only" warnings,
	but I cannot guarantee to have caught everything yet.

Hard-copy will be available at the meeting.

John

[elided]

1, answered,,
Summary-line: 27-Mar  John T Kohl                #Re: Revised GSSAPI spec
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA07205; Wed, 27 Mar 91 10:14:23 EST
Received: from QUICKSILVER.MIT.EDU by MIT.EDU with SMTP
	id AA22642; Wed, 27 Mar 91 10:14:15 EST
Received: by quicksilver (5.57/4.7) id AA15304; Wed, 27 Mar 91 10:14:09 EST
Date: Wed, 27 Mar 91 10:14:09 EST
From: John T Kohl <jtkohl@MIT.EDU>
Message-Id: <9103271514.AA15304@quicksilver>
To: "John Wray, Secure Systems Development" <wray@ultra.enet.dec.com>
In-Reply-To: John Wray, Secure Systems Development, DTN 226-6106  25-Mar-1991 1321's message of Mon, 25 Mar 91 10:59:45 PST,
	<9103251859.AA15288@enet-gw.pa.dec.com>
Subject: Re: Revised GSSAPI spec
X-Us-Snail: MIT Room E40-300, 1 Amherst St., Cambridge, MA 02139 USA

*** EOOH ***
Date: Wed, 27 Mar 91 10:14:09 EST
From: John T Kohl <jtkohl@MIT.EDU>
To: "John Wray, Secure Systems Development" <wray@ultra.enet.dec.com>
In-Reply-To: John Wray, Secure Systems Development, DTN 226-6106  25-Mar-1991 1321's message of Mon, 25 Mar 91 10:59:45 PST,
	<9103251859.AA15288@enet-gw.pa.dec.com>
Subject: Re: Revised GSSAPI spec

nitpick comments on the 3/25/91 draft:

sec 2.1.5, as mentioned, has a syntax error in the definition of the
gss_OID_set_desc structure.

3.3. "input_token" is used rather than "input_token_buffer" to describe
the parameter

p.17, "out-of-sequence" is spelled "out-or-sequence"

3.8 (p. 25/26) should the discussion of qop_req parallel that in 3.10,
e.g. specify gss_s_failure for unsupported strength?

3.10 (p. 27) a comma is missing after the qop_req parameter

3.12 (p. 31) "1" and "2" should be used as #defined values, to avoid
"magic numbers" in source code

3.16 (p. 34) top of page, the "de" of "code" is boldfaced

p.36, para 3, "distinguished" is misspelled


1,,
Summary-line: 17-Apr  John T Kohl                #Re: Revised GSSAPI spec (Draft "C", 4/2/91)
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA17386; Wed, 17 Apr 91 15:57:20 EST
Received: from QUICKSILVER.MIT.EDU by MIT.EDU with SMTP
	id AA27330; Wed, 17 Apr 91 16:57:16 EDT
Received: by quicksilver (5.57/4.7) id AA03609; Wed, 17 Apr 91 16:57:10 EDT
Date: Wed, 17 Apr 91 16:57:10 EDT
From: John T Kohl <jtkohl@MIT.EDU>
Message-Id: <9104172057.AA03609@quicksilver>
To: "John Wray, Secure Systems Development" <wray@ultra.enet.dec.com>
In-Reply-To: John T Kohl's message of Wed, 27 Mar 91 10:14:09 EST,
	<9103271514.AA15304@quicksilver>
Subject: Re: Revised GSSAPI spec (Draft "C", 4/2/91)
X-Us-Snail: MIT Room E40-300, 1 Amherst St., Cambridge, MA 02139 USA

*** EOOH ***
Date: Wed, 17 Apr 91 16:57:10 EDT
From: John T Kohl <jtkohl@MIT.EDU>
To: "John Wray, Secure Systems Development" <wray@ultra.enet.dec.com>
In-Reply-To: John T Kohl's message of Wed, 27 Mar 91 10:14:09 EST,
	<9103271514.AA15304@quicksilver>
Subject: Re: Revised GSSAPI spec (Draft "C", 4/2/91)

p.11, table 2-1.  what's the bit ordering of the encoding of the calling
errors?  presumably msb->lsb matches the order specified for the entire
32-bit quantity; just make it explicit?

p.17, section 3.3:  the "call again" sentence again fails to mention
that arguments other than input_token should be the same as for
previous calls.

p.19, "output_token" parameter.  if the return buffer length is zero,
should the caller still release the buffer after finishing its work?

p.22, section 3.4: again, mention that the other arguments need to
remain the same over multiple exchange calls.

p.33, "status_type" description: "gss_c_gss_code" is not all in one
typeface.

1,,
Summary-line:  1-May  Percy Tzelnic              #Meeting notes: Athena/Kerberos - DEC/SPX;  4/17/91 
Received: by E40-PO.MIT.EDU (5.45/4.7) id AA19456; Wed, 1 May 91 15:06:04 EDT
Received: from enet-gw.pa.dec.com by ATHENA.MIT.EDU with SMTP
	id AA12573; Wed, 1 May 91 15:05:41 EDT
Received: by enet-gw.pa.dec.com; id AA25416; Wed, 1 May 91 12:04:15 -0700
Message-Id: <9105011904.AA25416@enet-gw.pa.dec.com>
Received: from pmaxpt.enet; by decwrl.enet; Wed, 1 May 91 12:05:20 PDT
Date: Wed, 1 May 91 12:05:20 PDT
From: Percy Tzelnic <tzelnic@pmaxpt.enet.dec.com>
To: jis@ATHENA.MIT.EDU, "jtkohl@athena.mit.edu"@Pa.dec.com,
        "jfc@athena.mit.edu"@Pa.dec.com, "tytso@athena.mit.edu"@Pa.dec.com,
        kahn@zendia.enet.dec.com, linn@zendia.enet.dec.com,
        wray@ultra.enet.dec.com, kannan@sejour.enet.dec.com,
        kaufman@kibitz.enet.dec.com, tzelnic@Pa.dec.com
Subject: Meeting notes: Athena/Kerberos - DEC/SPX;  4/17/91 

*** EOOH ***
Date: Wed, 1 May 91 12:05:20 PDT
From: Percy Tzelnic <tzelnic@pmaxpt.enet.dec.com>
To: jis@ATHENA.MIT.EDU, "jtkohl@athena.mit.edu"@Pa.dec.com,
        "jfc@athena.mit.edu"@Pa.dec.com, "tytso@athena.mit.edu"@Pa.dec.com,
        kahn@zendia.enet.dec.com, linn@zendia.enet.dec.com,
        wray@ultra.enet.dec.com, kannan@sejour.enet.dec.com,
        kaufman@kibitz.enet.dec.com, tzelnic@Pa.dec.com
Subject: Meeting notes: Athena/Kerberos - DEC/SPX;  4/17/91 

Cc: ultra::lipner, ultra::gasser, ultra::modeen, zendia::sanders,
	erlang::patel, tl::lauck, mailto::frampton, nac::kirby, erlang::wilde,
	nac::tardo, took::schimpf, smurf::ferson, lassie::lawler, smurf::hu,
	smurf::williams
 
 
I am pleased to distribute these notes, which mark our reaching an important
milestone in agreeing on a common API across multiple authentication 
mechanisms, in particular Kerberos and SPX. (This API is based on John Linn's 
GSSAPI, and on  John Wray's corresponding C-binding.)
 
My thanks to you all.
 
Percy 
 
-------
 
<Notes taken by Kannan Alagappan>
 
 
 
Participants: 	
-------------
 DEC - Kannan Alagappan, Charlie Kaufman, John Linn,
       Percy Tzelnic, John Wray
 MIT - John Carr, John Kohl, Jeff Schiller, Ted T'so
 
Meeting goals: 
--------------
 1. Reach agreement on GSSAPI naming issue
 
Agenda (proposed):
------------------
 1. Opening remarks (goals, agenda, etc.)
 2. Discuss two issues with naming (handouts provided at meeting)
	a)  Name representation
	b)  Importing application information
 3. Discussion; action items, closure of the GSSAPI topic
 4. Closure and summary
 
Brief summary:
--------------
 The three hour discussion on naming was very lively!  It helped
 all of us understand the issues better.  Thanks to a compromise
 solution proposed by Jeff Schiller, we managed to reach agreement
 on the naming issue, which would allow building of portable applications
 (such as telnet and rlogin).  The proposal is not in itself
 sufficient to support construction of a single GSSAPI implementation
 supporting both mechanisms, though hooks remain for future generalization
 towards this goal.
 
 The summary of the agreements:
 
 1) "import" would accept a null nametype and a string of the form
    "SERVICE:service@host-as-internet-name".  (Acceptance of null nametype
    is in addition to implementations' acceptance of any non-null nametypes
    they choose to register and support.)
 2) "display" would produce names of the form "KERBEROS:service.inst@realm" 
    in the case of Kerberos and "SPX:/C=US/.../CN=foo" for SPX.  (It was
    strongly argued at the meeting that identifiers of name types should be
    independent of mechanisms.)
 3) We will continue discussions of other possible nameforms at future 
    meetings.
 
Discussion:
-----------
 The discussion on name representation covered the following points:
 - It was observed that authentication names at some level (either as
   an input argument specified by a user or as a name on an ACL entry)
   need to be represented as printable strings.
 - Athena stated their strong preference for using printable string names
   across the API, emphasizing the simplicity and ease of implementation
   for their mechanism.  Cost and FTP availablility of X/Open standards was
   another Athena concern.
 - The current C-binding spec calls for names to be represented 
   only in the X/OPEN format, stressing that no canonical printable
   name representation exists and therefore the X/OPEN format makes
   sense - as an emerging standard.
 - An alternate proposal was submitted, for names to be represented as an
   opaque pointer and a tag, where the tag determines the structure
   pointed at.  Each mechanism could decide on which name types
   it was willing to support (if more than one.)  However, some
   participants found this solution unacceptable since it required
   an extra argument for every name.
 - Jeff Schiller proposed a compromise solution whereby names are
   represented as opaque structures without tagging.  The decision on
   how API-internal names are actually represented is left to each GSSAPI
   implementation.
 - As an implication of API-internal names' opacity, portable applications
   will be able to generate authenticable names only by invoking "import_name"
   and to examine them only by examining the output from "display_name."
   "compare_name" remains available as a means to compare API-internal names.
   No portable application will be able to depend on the structure of
   API-internal names.
 
 The discussion on importing application information covered a wide
 range of topics such as the need for a "name_glue" routine, the
 different types of names, and how authorization might work in the
 current spec.  Without summarizing the entire discussion, I would
 like to highlight the major points.
 - It was observed that Kerberos and SPX applications authenticate
   server principals with different granularity.  Therefore the
   initial conversation focused on how to represent this difference
   of authentication granularity at the interface.
 - The current C binding spec proposes a printable string and a name type
   OID, which determines the syntactic coding of the printable string, as
   input to the "import" function.
 - An alternate solution proposed that we hide the name type OID from
   application developers by explicitly passing the `generic' target
   information to a modified "import" function.  [Described in handout.]
 - Jeff Schiller proposed that the modified "import" function should
   actually be an additional alternative to "import_name", not a
   replacement for it.  Also, Jeff referred to it as a private, rather
   than a GSS routine.
 - It was observed that the authorization model in the current spec
   requires that each ACL entry be imported to an internal name format.
   Then, the internal name is compared with the name returned from an accept
   context call.  Jeff pointed out that two names which compare successfully
   may not be sufficient to authorize a user access to a service.  We agreed
   not to try to solve multiple trust paths issues at this time.
 - Jeff and Ted T'so stated that the name being passed into the "import"
   function should be a self-describing printable name in order for
   authorization to work.  Ted pointed out that the current C binding
   spec for "display_name" should be fixed to return an OID parameter
   to describe the type of the output name.  We discussed adding an input
   name_type OID parameter to "display_name", qualifying the translation
   from internal form, but no consensus was reached on this point.
 - Jeff expanded the discussion on self-describing printable names.  He
   observed that the GSSAPI should be able to import authentication names
   such as "SERVICE:service@host-as-internet-name" and "UID:uid".  Note that
   these names would be created by the application developer and they would
   not appear on ACLs.
 - Also, the GSSAPI should be able to import authentication names that
   appear on ACLs such as "KERBEROS:service.inst@realm" and
   "SPX:/C=US/.../CN=foo".  We should seek further agreements for
   self-descriptive printable forms (e.g., for X.500 names.)
 - Jeff Schiller proposed a compromise solution whereby the "import"
   function will accept a self-describing printable name and a NULL
   name type.  Specification of a NULL input_name_type to import_name will
   indicate that the input name's interpretation is not specified through
   the OID mechanism, thus it is a local matter based on interpretation of the
   input string.
 - In order to achieve SPX <-> Kerberos portability by working around the
   current mismatch between SPX node-granularity verifier credentials and
   conventional Kerberos service-granularity verifier credentials, we made
   an implementors' agreement that both implementations of import_name will
   be able to accept (along with a NULL input_name_type tag) the form:
   "SERVICE:service@host-as-internet-name."
   No restrictions on the output of display_name were defined.  Other API
   external name forms will be defined by mechanism designers, hopefully
   to converge in later agreements.
 
Action items:
-------------
    1. John Wray to issue a revised version of the spec.
 
    2. Develop a prototype of the GSSAPI and demonstrate application
       portability across Kerberos and SPX (Ted T'so and Kannan Alagappan.)
 
    3. Meet, after we have a working prototype, to discuss what we've
       learned from this work.
