[comp.protocols.kerberos] kerberos application to OSI

salzman@HPLABS.HP.COM (Michael M. Salzman) (12/08/89)

This is a two pronged question, prompted by recent user questions on 
the net.

Are efforts underway at Athena to integrate Kerberos mechanisms with
OSI protocol services?  Is this desirable?  Is it feasible?

The second aspect relates to the notion of a user space or environment
which is both authenticated and available network wide.  It would seem
useful to incorporate the authentication features of Kerberos within
a service such as X.500, so that users in one domain could access 
services in another domain, without prior arrangement.  Similarly, a user
could travel to another location and have his environment available
to him including authentication information.

I suspect that such activities would require another layer of
authentication between cooperating Directory Service Agents, since
they would have to trust the information provided by the remote
DSAs.  Such a trust establishment mechanism could also use Kerberos,
and would be administered by a higher level authority which would 
manage the inter DSA authentication.

I think that a marriage of kerberos and distributed directory/environment
services would be well received in the corporate world, and would
solve a real problem.


Mike Salzman

lloyd@XLNVAX.EXCELAN.COM (Lloyd Spencer) (12/09/89)

> Are efforts underway at Athena to integrate Kerberos mechanisms with
> OSI protocol services?  Is this desirable?  Is it feasible?

I would whole-heartedly support the incorporation of a Kerberos-like
services into FTAM, for example.  The current unencoded password scheme
is rather poor, and therefore leaves me to conclude that any proposed
security scheme is better than none (well, in effect none).  Although
it is not my intention to be unduly critical of the FTAM specification
nor its proponents, I would like to see more attention given to security.

Similarly, I would like to know whether there is an effort to integrate
a Kerberos-like service with OSI application services, such as FTAM,
for example?  We (i.e. Novell) would be interested in assisting and/or
following up on this area since security is a key concern (yes, even
in the area of OSI).

-----------------------------------------------------------------------
Lloyd Spencer
Novell, Inc.
Product Marketing
2180 Fortune Drive
San Jose, CA  95131

Phone   : (408) 473-8242
UUCP    : {ames,sun,apple,amdahl,mtxinu,cae780}!excelan!lloyd
Internet: lloyd@novell.com
          lloyd@excelan.com
-----------------------------------------------------------------------

barlow@DECWET.ENET.DEC.COM (Repatriated Treehugger) (12/09/89)

Lloyd Spencer writes:

      > I would whole-heartedly support the incorporation of a Kerberos-like
      > services into FTAM, for example.  The current unencoded password
      > scheme is rather poor, and therefore leaves me to conclude that any
      > proposed security scheme is better than none (well, in effect none).
      > Although it is not my intention to be unduly critical of the FTAM
      > specification nor its proponents, I would like to see more attention
      > given to security.
      >
      > Similarly, I would like to know whether there is an effort to
      > integrate a Kerberos-like service with OSI application services, such
      > as FTAM, for example?  We (i.e. Novell) would be interested in
      > assisting and/or following up on this area since security is a key
      > concern (yes, even in the area of OSI).

    Note that the password encoding within FTAM is expressed as

        Password ::= [APPLICATION 17] CHOICE {
            GraphicString,
            OCTET STRING }

    The octet string encoding choice was explicitly placed there for future
    use of better authentication techniques than graphicstring passwords.
    Stick your Kerberos ticket in there, and you've got strong
    authentication, and are completely ISO conformant!

Doug Barlow
Ex ANSI FTAM Rapporteur
Digital Equipment Corporation

philf@xymox.metaphor.com (Phil Fernandez) (12/14/89)

In article <8912080934.AA11988@sytek.hls.hac.com> sytek!salzman@HPLABS.HP.COM (Michael M. Salzman) writes:
>I think that a marriage of kerberos and distributed directory/environment
>services would be well received in the corporate world, and would
>solve a real problem.

Speaking as the leader of Unix System Software Engineering at Metaphor,
we'd be *extremely* interested in a "marriage" of Kerberos and OSI
distributed directory services.  It will solve a real problem for us.

We will be exploring this concept over the next several months.  I'd
be interested in exchanging mail with other interested folks.

pmf

+-----------------------------+----------------------------------------------+
| Phil Fernandez              |             philf@metaphor.com               |
|                             |     ...!{apple|decwrl}!metaphor!philf        |
| Metaphor Computer Systems   |"Does the body rule the mind, or does the mind|
| Mountain View, CA           | rule the body?  I dunno..." - Morrissey      |
+-----------------------------+----------------------------------------------+

andrew@cc.brunel.ac.uk (Andrew Findlay) (12/15/89)

In article <8912080934.AA11988@sytek.hls.hac.com> sytek!salzman@HPLABS.HP.COM (Michael M. Salzman) writes:
>
>The second aspect relates to the notion of a user space or environment
>which is both authenticated and available network wide.  It would seem
>useful to incorporate the authentication features of Kerberos within
>a service such as X.500, so that users in one domain could access 
>services in another domain, without prior arrangement.  Similarly, a user
>could travel to another location and have his environment available
>to him including authentication information.

X.500 already has the features you want. The standard provides for strong
(public key) authentication between users and DSAs, and also between
one DSA and another. The issue of key management is also addressed, though
if DSA-to-DSA authentication is needed, there has to be a trusted
Certification Authority. Mechanisms are defined to establish a "chain of
trust" between DSAs that may not have previously communicated.

For the full details see X.509 / ISO 9594-8 "The Directory - Authentication
Framework".

In principle, it would be possible to store each user's "environment" in
the X.500 Directory. The login program would then need to incorporate a
Directory User Agent so that the user could locate their entry when on a
remote site. The "environment" would have to describe the location of the
home directory etc - presumably to be accessed by FTAM...

Andrew

-- 

---------------------------------------------------------------------
|  From Andrew Findlay at Brunel University, Uxbridge, UB8 3PH, UK  |
|  Andrew.Findlay@brunel.ac.uk          phone: +44 895 74000 x2512  |
---------------------------------------------------------------------