[AFS3-std] New Version Notification for draft-wilkinson-afs3-rxgk-08.txt (fwd)

[Benjamin Kaduk]

I have redone the rxgk text on the GSS negotiation loop to refer to a
separate document which defines the loop structure. There's still a
couple pages of description in section 6.2, but it's just things like how
GSS tokens and errors are communicated to the other peer, and required
flags on the security context. Do people think this is an improvement?

I've sent the separate document on the GSS neogtiation loop to the kitten
WG for comments; that document is
http://tools.ietf.org/html/draft-kaduk-kitten-gss-loop-00

-Ben

---------- Forwarded message ----------
Date: Mon, 21 Oct 2013 16:03:41 -0700
From: internet-***@ietf.org
To: Simon Wilkinson <***@sxw.org.uk>, Benjamin Kaduk <***@mit.edu>
Subject: New Version Notification for draft-wilkinson-afs3-rxgk-08.txt


A new version of I-D, draft-wilkinson-afs3-rxgk-08.txt
has been successfully submitted by Simon Wilkinson and posted to the
IETF repository.

Filename: draft-wilkinson-afs3-rxgk
Revision: 08
Title: rxgk: GSSAPI based security class for RX
Creation date: 2013-10-22
Group: Individual Submission
Number of pages: 28
URL: http://www.ietf.org/internet-drafts/draft-wilkinson-afs3-rxgk-08.txt
Status: http://datatracker.ietf.org/doc/draft-wilkinson-afs3-rxgk
Htmlized: http://tools.ietf.org/html/draft-wilkinson-afs3-rxgk-08
Diff: http://www.ietf.org/rfcdiff?url2=draft-wilkinson-afs3-rxgk-08

Abstract:
rxgk is a security class for the RX RPC protocol. It uses the GSSAPI
framework to provide an authentication service that provides
authentication, confidentiality and integrity protection for the rxgk
security class. This document provides a general description of rxgk
and how to integrate it into generic RX applications. Application
specific behaviour will be described, as necessary, in future
documents.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

[Michael Meffie]

On Mon, 21 Oct 2013 19:09:34 -0400

Post by Benjamin Kaduk
I have redone the rxgk text on the GSS negotiation loop to refer to a
separate document which defines the loop structure. There's still a
couple pages of description in section 6.2, but it's just things like how
GSS tokens and errors are communicated to the other peer, and required
flags on the security context. Do people think this is an improvement?

Thank you for draft 8 Ben. Yes, this is an improvement.

Post by Benjamin Kaduk
I've sent the separate document on the GSS neogtiation loop to the kitten
WG for comments; that document is
http://tools.ietf.org/html/draft-kaduk-kitten-gss-loop-00

Thank you Ben. I see there was some interest in the kitten working group. From
reading the comments there, my main understanding was, how does the kitten-gss-loop-00
overlap with RFC 2743?

[Benjamin Kaduk]

Post by Michael Meffie
On Mon, 21 Oct 2013 19:09:34 -0400

Post by Benjamin Kaduk
I have redone the rxgk text on the GSS negotiation loop to refer to a
separate document which defines the loop structure. There's still a
couple pages of description in section 6.2, but it's just things like how
GSS tokens and errors are communicated to the other peer, and required
flags on the security context. Do people think this is an improvement?

Thank you for draft 8 Ben. Yes, this is an improvement.

Post by Benjamin Kaduk
I've sent the separate document on the GSS neogtiation loop to the kitten
WG for comments; that document is
http://tools.ietf.org/html/draft-kaduk-kitten-gss-loop-00

Thank you Ben. I see there was some interest in the kitten working group. From
reading the comments there, my main understanding was, how does the kitten-gss-loop-00
overlap with RFC 2743?

I spent some time looking into that question this week, and the answer
seems to be that draft-kaduk-kitten-gss-loop-00 imposes only a very minor
additional requirement on applications (using RFC 2743 as a baseline),
namely that "all" input parameters to
gss_init_sec_context/gss_accept_sec_context must remaine fixed throughout
the course of the negotiation loop, instead of just the credential handle.

This is a minor enough detail that I think we're going to end up making
the gss-loop document purely informational, and continue to rely on RFC
2743 as the normative reference. My plan is to make a gss-loop-01 with
that change (and sample code), and then do an rxgk-09 with updated
references accordingly.

-Ben

[Benjamin Kaduk]

This is a minor enough detail that I think we're going to end up making the
gss-loop document purely informational, and continue to rely on RFC 2743 as
the normative reference. My plan is to make a gss-loop-01 with that change
(and sample code), and then do an rxgk-09 with updated references
accordingly.

rxgk-09 is up. (It really was very minor changes from -08.) I also fixed
an internal inconsistency about encoding GSS major status codes for the
wire.

http://tools.ietf.org/html/draft-wilkinson-afs3-rxgk-09

-Ben