Subject: Re: Draft advancement criteria for GSS RFCs?

From: Mayank Upadhyay <[email-masked]>
Date: Mon, 2 Apr 2001 12:34:21 -0700 (PDT)

>Last summer, we determined that the CAT-WG had completed IESG submission of
>its active and chartered work items, except for those Kerberos documents
>which were transitioned to the new Kerberos WG.  It was agreed at that point
>that, while not initiating new work, the CAT-WG would remain open as a means
>to process subsequent advancement of CAT's RFCs. The goal of this message is
>to sample the membership to see whether we have the basis for requesting
>that RFCs 2743 and 2744 be advanced to Draft Standards. I'd appreciate any
>reports to the list on the state of experience gained with applications
>using RFCs 2743 and 2744 as a basis for layering over GSS providers.  
>

John,

Here's some information from the Java side of GSS-API:

Sun has a Java implementation of GSS-API based on RFC's 2853 and 2743 that 
supports Kerberos v5. We've run simple tests and interoperated successfully 
against C implementations of Solaris GSS-API, the latest MIT Kerberos 
release, and Windows 2000 SSPI. We've exercised context establishment with 
mutual authentication, delegation and confidentiality using Kerberos v5 as 
the underlying mechanism. The tests call wrap/unwrap and getMIC/verifyMIC for 
per-message protection, and use delegated credentials to establish further 
contexts.

Another application that calls into Java GSS-API is our Java LDAP client that 
uses the SASL-GSS mechanism with Kerberos. It successfully interoperates with 
a Windows 2000 active directory server that uses SASL-GSS.

Regarding the GSS-API model, perhaps the only constrain we faced in our Java 
implementation was the lack of a conversation function. Our GSS-API library 
can't always depend on there being a local Kerberos provider's credential 
cache given the mobile nature of the code, and applications/applets sometimes 
need to perform a login to obtain initial credentials.

I will be posting some comments shortly about the Java language bindings in 
RFC 2853 including areas where minor modifications are needed.

Thanks,
Mayank
_______________________________

Mayank Upadhyay
Java Security and Networking
Sun Microsystems, Inc.
mailto:[email-masked]
Tel: (408) 517-5956
Fax: (408) 863-3155

-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]

---

From: Thomas_Owusu/[email-masked]
Date: Thu, 5 Apr 2001 14:15:43 -0500

IBM/Tivoli also has a Java GSSAPI implementation based on RFC 2743 and the
Java bindings RFC 2853.
It uses Kerberos v5 as the default mechanism. It has undergone extensive
interoperability testing and is used in
IBM products.

---
Thomas Owusu
Java Security
Tivoli Systems
Email: [email-masked]
Tel: (512) 436 9835

Mayank Upadhyay <[email-masked]>@lists.Stanford.EDU on 04/02/2001
02:34:21 PM

Please respond to Mayank Upadhyay <[email-masked]>

Sent by:  [email-masked]

To:   [email-masked], [email-masked]
cc:
Subject:  Re: Draft advancement criteria for GSS RFCs?

John,

the underlying mechanism. The tests call wrap/unwrap and getMIC/verifyMIC
for

Another application that calls into Java GSS-API is our Java LDAP client
that
uses the SASL-GSS mechanism with Kerberos. It successfully interoperates
with
a Windows 2000 active directory server that uses SASL-GSS.

Regarding the GSS-API model, perhaps the only constrain we faced in our
Java
implementation was the lack of a conversation function. Our GSS-API library
can't always depend on there being a local Kerberos provider's credential
cache given the mobile nature of the code, and applications/applets
sometimes
need to perform a login to obtain initial credentials.

Thanks,
Mayank

Mayank Upadhyay