Work Group Last Call: Desired Enhancements to GSSAPI Naming

I am happy to announce the start of a two week working group last call
for the Kitten work item "Desired Enhancements to GSSAPI Naming".
http://www.ietf.org/internet-drafts/draft-ietf-kitten-gss-naming-03.txt

This document is intended to be published as Informational.  The
document provides scope for the naming issues Kitten is attempting to solve.

Please perform another review and send feedback to the list.

This WGLC ends at midnight EST on Nov 23, 2005.

Jeffrey Altman

_______________________________________________
Kitten mailing list
Kitten <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten

Kitten Meeting at IETF64

Kitten (GSS-API Next Generation) WG (kitten)

WEDNESDAY, November 9, 2005
0900-1130 (UTC-8) Morning Session I

==============================================================================

CHAIR: Jeffrey Altman <jaltman <at> columbia.edu>

Presentation Materials (search for Kitten):

  https://onsite.ietf.org/public/meeting_materials.cgi?meeting_num=64

Audio Stream:

  http://videolab.uoregon.edu/events/ietf/
  http://videolab.uoregon.edu/events/ietf/ietf648.m3u

Jabber:
  server: ietf.xmpp.org
  room:   kitten

AGENGA:

Preliminaries - Jeffrey Altman (5 min)
  - Introduction
  - Blue Sheets
  - Scribe, Jabber
    http://www.xmpp.org/ietf-chat.html
  - Agenda Bashing

New draft for Kitten (GSS_API V2: C# Bindings)

This e-mail is being sent to submit the:

  GSS_API V2: C# Bindings
  draft- ietf- kitten- gssapi- csharp- bindings- 00.txt

as a Kitten working group draft.

Thank you,

Juan Carlos Luciani
jluciani <at> novell.com

NETWORK WORKING GROUP                                      J. C. Luciani
INTERNET-DRAFT                                              Novell, Inc.
Expires: April 8, 2006                                  November 8, 2005

                        GSS_API V2: C# Bindings
               draft-ietf-kitten-gssapi-csharp-bindings-00.txt


Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she becomes aware will be disclosed, in accordance with
   Section 6 of BCP 79.

Re: New draft for Kitten (GSS_API V2: C# Bindings)

The Secretariat CANNOT process your Internet-Draft submission due to
following reason(s):

 * All Internet-Drafts must include the following statement:

Copyright (C) The Internet Society (2005).

> This e-mail is being sent to submit the:
>
>   GSS_API V2: C# Bindings
>   draft- ietf- kitten- gssapi- csharp- bindings- 00.txt
>
> as a Kitten working group draft.
>
> Thank you,
>
> Juan Carlos Luciani
> jluciani <at> novell.com
>
>

Re-submit of GSS_API:V2 C# Bindings draft

This e- mail is being sent to re-submit the:

  GSS_API V2: C# Bindings
  draft-  ietf-  kitten-  gssapi-  csharp-  bindings-  00.txt

as a Kitten working group draft. The draft is being
re-submitted to correct the copyright date.

Thank you,

Juan Carlos Luciani
jluciani <at> novell.com

NETWORK WORKING GROUP                                      J. C. Luciani
INTERNET-DRAFT                                              Novell, Inc.
Expires: April 8, 2006                                  November 8, 2005

                        GSS_API V2: C# Bindings
               draft-ietf-kitten-gssapi-csharp-bindings-00.txt


Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she becomes aware will be disclosed, in accordance with

IETF64 Kitten WG Summary

The Kitten working group met at IETF64 on Wednesday morning.

The presentation materials are available at:
   https://onsite.ietf.org/public/meeting_materials.cgi?meeting_num=64

The Audio Stream is available at

http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf64/ietf64-ch8-wed.mp3.1

The Jabber Logs are available at:

http://www.xmpp.org/ietf-logs/kitten <at> ietf.xmpp.org/2005-11-09.html

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

The Kitten Working Group continued its efforts to use the IETF meeting
time for providing high-bandwidth work time to make progress on active
documents.   Unlike the Paris meeting, this room suffered from a lack
of microphones sufficient facilitate our purpose.   I propose that rooms
should provide five microphones.  One for the chair, one wireless for
the presenter, two microphones for front row participants who have read
the documents, and one floor microphone for others.

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

Summary of document status:

* PRF API extension for GSS draft -07 submitted to IESG

* PRF API extension for GSS KRB5 mech draft -04 submitted to IESG

Re: Re-submit of GSS_API:V2 C# Bindings draft

Please delet the following and resubmit. Thank you.

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.

> This e- mail is being sent to re-submit the:
>
>   GSS_API V2: C# Bindings
>   draft-  ietf-  kitten-  gssapi-  csharp-  bindings-  00.txt
>
> as a Kitten working group draft. The draft is being
> re-submitted to correct the copyright date.
>
> Thank you,
>
> Juan Carlos Luciani
> jluciani <at> novell.com
>
>

AD review of draft-ietf-kitten-gssapi-prf-07

The The following are AD review comments for the GSSAPI PRF draft.  I may end up issuing a last call while these
comments are still under discussion.

1) Update the reference to RFC 1750 to the document that obseletes it.

2) Part of the document implies that the output should be as long as
   requested by the requester; part says that it may be shorter.  Which is it?

     If the implementation cannot produce the desired output due to lack
     of resources then it MUST return GSS_S_FAILURE and MUST set a
     suitable minor status code.

     Mechanisms MAY limit the output of the PRF, possibly in ways related
     to the types of cryptographic keys available for the PRF function,
     thus the prf_out output of GSS_Pseudo_random() MAY be smaller than

I think you need to give enough advice to tell applications whether
they should expect to need counters and other extension mechanisms if
they call the PRF for reasonably short outputs like the sizes of
common crypto keys.  I hope the answer is no.

Last Call: 'A PRF API extension for the GSS-API' to Proposed Standard

The IESG has received a request from the Kitten (GSS-API Next Generation) WG to

consider the following documents:

- 'A PRF API extension for the GSS-API '
   <draft-ietf-kitten-gssapi-prf-07.txt> as a Proposed Standard
- 'A PRF for the Kerberos V GSS-API Mechanism '
   <draft-ietf-kitten-krb5-gssapi-prf-04.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg <at> ietf.org or ietf <at> ietf.org mailing lists by 2005-11-30.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-prf-07.txt
http://www.ietf.org/internet-drafts/draft-ietf-kitten-krb5-gssapi-prf-04.txt

Interesting multi-mech/multi-bindings exported sec context token issue

Exported security context tokens, unlike exported name tokens, have no
header identifying a mechanism or anything else.

Multi-mechanism non-monolythic implementations of the GSS-API can deal
with this by adding a header to the token as output by a mechanism and
then stripping it off prior to calling the mechanism to import it.

That works well enough, and it is what Solaris' libgss does.

But think now of a Java implementation where some mechanisms are
implemented in Java, and some are accessed through a Java bridge to an
independent implementation through C bindings.

This approach then doesn't work in such a situation because a security
context token exported through the Java bindings but for a mechanism
accessed through the bridge to the C bindings cannot then be imported by
an application using only the C bindings -- the C implementation won't
expect the header added by the Java bindings.

Thoughts?

Nico
--

--