Subject: I-D ACTION:draft-ietf-kitten-gssapi-prf-05.txt

From: [email-masked]
Date: Mon, 01 Aug 2005 15:50:01 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Kitten (GSS-API Next Generation) Working Group of the IETF.

	Title		: A PRF API extension for the GSS-API
	Author(s)	: N. Williams
	Filename	: draft-ietf-kitten-gssapi-prf-05.txt
	Pages		: 9
	Date		: 2005-8-1
	
This document defines a Pseudo-Random Function (PRF) extension to the
   Generic Security Service Application Programming Interface (GSS-API)
   for keying application protocols given an established GSS-API
   security context.  The primary intended use of this function is to
   key secure session layers that don't or cannot use GSS-API per-
   message MIC (message integrity check) and wrap tokens for session
   protection.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-prf-05.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-kitten-gssapi-prf-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-kitten-gssapi-prf-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Kitten mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/kitten

---

From: Seema Malkani <[email-masked]>
Date: Tue, 02 Aug 2005 17:20:41 -0700

In reference to the Java Bindings for PRF, I would prefer not to mention
any Java interface/class/method names in this draft. All the Java
Bindings for the new GSS extensions will be submitted separately.

Thanks,
Seema

[email-masked] wrote:

>------------------------------------------------------------------------
>

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 03 Aug 2005 03:41:23 +0200

> Bindings for the new GSS extensions will be submitted separately.

Seema:

By doing so what you are doing is imposing a significant delay on the
ability of Java applications to be able to support prf() functionality
prior to the completion of a final GSSv3 API RFC.  Only when Kitten
have submitted this document will a complete Java GSSv3 binding document
be available.  Applications that take advantage of the prf() are going
to be in use long before that.

I believe the document is careful to not alter any of the currently
defined interfaces.  It merely states that if a Java implementation
provides this method it will have the specified prototype and the
class that implements will also implement the interface.  Introspection
will have to be used by the application to determine if it is present
or not.  This is the way that all "extension" methods would have to
be implemented since it is not possible to extend interfaces in Java.

Can you please explain your reasoning to the working group?

Thanks

Jeffrey Altman

---

From: Seema Malkani <[email-masked]>
Date: Wed, 03 Aug 2005 23:23:08 -0700

Jeffrey,

We have not decided on how PRF will be available in the Java Bindings. 
Hence, we should not mention any Java interface/class here.

Currently section 2.2 states:

For Java GSS_Pseudo_random() maps to a method, 'prf', of the class
that implements the GSSContext interface.

This should be modified to:
For Java GSS_Pseudo_random() maps to a method, 'prf'.

Thanks,
Seema

---

From: Sam Hartman <[email-masked]>
Date: Fri, 12 Aug 2005 15:14:10 -0400

>>>>> "Seema" == Seema Malkani <[email-masked]> writes:

    Seema> Jeffrey, We have not decided on how PRF will be available
    Seema> in the Java Bindings. Hence, we should not mention any Java
    Seema> interface/class here.

    Seema> Currently section 2.2 states:

    Seema> For Java GSS_Pseudo_random() maps to a method, 'prf', of
    Seema> the class that implements the GSSContext interface.

    Seema> This should be modified to: For Java GSS_Pseudo_random()
    Seema> maps to a method, 'prf'.

I would rather us remove all references to Java until this can be
decided.

---

From: Jeffrey Altman <[email-masked]>
Date: Mon, 29 Aug 2005 09:25:35 -0400

> I would rather us remove all references to Java until this can be

Later today draft-ietf-kitten-gssapi-prf-07 will be published.
This draft is identical to draft -06 which was published on Friday
except that the Normative reference to RFC2853 will have been
removed.

The primary change in -06/07 is to remove all references to the
Java Bindings.   Recent discussions have brought to light a conflict
between the IETF and Java Community Process (JCP) <http://jcp.org>.

A bit of history.  RFC 2853 was originally a product of the IETF
CAT working group.  Before Sun implemented it in the Java Class
Libraries the content of 2853 was submitted to the JCP and it became
JSR 72 <http://jcp.org/en/jsr/detail?id=72>.   Under the guidelines
of the JCP, all future changes to the Java GSS API must be developed
under JSR 72 and must be approved via the JCP procedures
<http://jcp.org/en/procedures/jcp2>.   In essence, the JCP is a
standards organization with membership requirements and procedures
that conflict with those in the IETF.

At the present time, neither the IETF nor the JCP are willing to
simply accept the work performed by the other.  Therefore, it appears
that those who are interested in the Java work must choose between
one of the two organizations.   I believe there are two choices:

(1) The JCP can be petitioned to allow the work of the IETF to be the
definitive source of specifications for Java GSS under JSR 72.  In this
case all work would be done in this working group.  The Kitten mailing
list traffic could be forwarded to the JSR 72 mailing list provided that
JSR 72 participants are informed that the IETF Note Well applies to JSR
72.  The Java GSS work would continue to be Standards track.

(2) The JCP JSR 72 can be the home to work on Java GSS.  Discussions
related to Java Bindings can take place on the Kitten mailing list but
there will be no Java items on the Kitten charter.  When a new JCP
specification is defined the authors can submit a publication request
to the RFC Editor for Informational publication.   The Java GSS work
would not be Standards track.

Seema is researching the options and will come back to this group with
her selection.   In the meantime, while discussion of Java GSS may
continue, I have requested that Nico remove all references to Java from
the existing documents we are trying to move forward to the IESG.
Once -07 is published, I will issue a WGLC on the document.

Jeffrey Altman

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 29 Aug 2005 11:20:32 -0400

> one of the two organizations.   I believe there are two choices:

There is a third option, which is to carry on the work jointly in both 
organizations.  The IETF has done joint work with other SDO's in the past; 
I think it might be worthwhile to consult with our AD and find out what it 
would take to do so in this case.

-- Jeff

---

From: Jeffrey Altman <[email-masked]>
Date: Mon, 29 Aug 2005 12:25:21 -0400

Jeffrey Hutzelman wrote:

> organizations.  The IETF has done joint work with other SDO's in the
> past; I think it might be worthwhile to consult with our AD and find out
> what it would take to do so in this case.
> 
> -- Jeff

The working group would approach the IAB to establish a liason
relationship with the JCP (aka Sun Microsystems, Inc.).

Jeffrey Altman