This is a static archive of the previous Open Grid Forum GridForge content management system saved from host forge.ogf.org file /sf/sfmain/do/go/artf3461?nav=1&selectedTab=comments at Sun, 06 Nov 2022 08:41:34 GMT SourceForge : artf3461: (1589) MyProxy Protocol

Project Home

Tracker

Documents

Tasks

Source Code

Discussions

File Releases

Wiki

Project Admin
Search Tracker
Project: Editor     Trackers > Published > View Artifact
Artifact artf3461 : (1589) MyProxy Protocol
Tracker: Published
Title: (1589) MyProxy Protocol
Description:
This document describes a protocol for storing and retrieving X.509 proxy credentials [RFC3820] to and from a server. 
The protocol allows long-lived keys to be secured on the server while allowing convenient access to short-lived proxy 
credentials as needed. The protocol was first implemented in September 2000 and has been widely used in grids for over 
four years.
.
Submitted By: Olle Mulmo
Submitted On: 08/16/2005 7:34 AM EST
Last Modified: 05/06/2007 4:46 AM EDT
Closed: 12/11/2005 10:48 PM EST

Status / Comments Change Log Associations Attachments (4)  
Status  
Group: *
Status:* Closed
Category: *
Customer: *
Priority: * 0
Assigned To: * None
Reported in Release: *
Fixed in Release: *
Estimated Hours: * 0
Actual Hours: * 0
resolution: *
Comments
Greg Newby: 05/06/2007 4:46 AM EDT
  Action: Update
resolution changed from PUBLISHED to none (no value)
Greg Newby: 02/13/2006 2:55 AM EST
  Comment:
Mass Update
  Action: Update
resolution changed from <None> to PUBLISHED
Greg Newby: 12/11/2005 10:48 PM EST
  Comment:
Mass Update
  Action: Update
artifact_status changed from Open to Closed
close_date changed from - to 2005-12-11 18:48:58
Greg Newby: 11/28/2005 9:11 PM EST
  Action: Update
artifact_group changed from Individual Submission to <None>
artifact_status changed from Closed to Open
Category changed from Experimental to <None>
group_artifact_id changed from Submit GGF Draft to Published
Priority changed from 5 to -
resolution changed from Published to <None>
summary changed from MyProxy Protocol version 2 to MyProxy Protocol
Joel Replogle: 11/27/2005 3:57 PM EST
  Comment:
Published as GFD.54 27 November, 2005.
  Action: Update
Joel Replogle: 11/27/2005 3:57 PM EST
  Action: Update
artifact_status changed from ready to publish to Closed
assigned_to changed from 9357 to 100
close_date changed from - to 2005-11-27 15:57:13
Priority changed from 1 to 5
Greg Newby: 11/23/2005 7:34 PM EST
  Comment:
Ok, no problem - fixed in the new upload.
  Action: Update
Greg Newby: 11/23/2005 7:34 PM EST
  Attachment: GFD-E.54.doc (75 KB)
  Action: Update
File Deleted changed from 703: GFD-E.54.doc to none (no value)
File added set to 706: GFD-E.54.doc
Jim Basney: 11/23/2005 7:00 PM EST
  Comment:
My preference would be to not have "Version 2" in the title, if that's OK.  This document describes the only public version of the protocol.  Thanks.
  Action: Update
Greg Newby: 11/23/2005 6:30 PM EST
  Comment:
Thanks for your efforts on this submission.  This
will be published as GFD-054.

Other than updating the header with this GFD #,
the only change I made was to add "Version 2" to the
title in the document - I presume this is the intent,
and acceptable.

Thanks again!
  Action: Update
Greg Newby: 11/23/2005 6:30 PM EST
  Action: Update
File added set to 703: GFD-E.54.doc
artifact_status changed from Pending Info from Authors to ready to publish
assigned_to changed from 302 to 9357
Priority changed from 4 to 1
resolution changed from <None> to Published
Jim Basney: 11/22/2005 6:51 PM EST
  Comment:
Here's a new version of the document addressing the helpful comments received in the public comment period.  I made the following changes:

- Added a paragraph on pipelining in section 3
- Replaced ASCII with UTF-8 to allow internationalization
- Added a paragraph to the security considerations section and also
   in the 'Put' section about client authorization
- Specified that certificates and certificate requests are DER-encoded
- Specified the byte encoding the number of certificates is 
   unsigned binary with maximum 255

I believe the document is now ready for final editor review.
  Action: Update
Jim Basney: 11/22/2005 6:51 PM EST
  Attachment: draft-ggf-basney-myproxy.doc (75.5 KB)
  Action: Update
File added set to 702: draft-ggf-basney-myproxy.doc
Greg Newby: 11/21/2005 7:21 PM EST
  Comment:
Author: Please review public comments here:
  https://forge.gridforum.org/forum/forum.php?forum_id=570

You can respond in that tracker, or in this one -- perhaps
also by uploading a new version of the document.  When it
is ready for the next step (final editor review), please
indicate that in this tracker.
  Action: Update
Greg Newby: 11/21/2005 7:21 PM EST
  Action: Update
artifact_status changed from Public Comment Period to Pending Info from Authors
assigned_to changed from 9357 to 302
Priority changed from 3 to 4
Greg Newby: 10/09/2005 7:52 PM EST
  Comment:
Thanks.  This will now go to 30-day public comment.  It
might take an extra few days to get announced, since
GGF15 just ended.  We'll post the public comment
tracker link here, and will end public comment 30 days
after the posting.
  Action: Update
Greg Newby: 10/09/2005 7:52 PM EST
  Action: Update
artifact_status changed from Returned to Author(s) to Public Comment Period
assigned_to changed from 477 to 9357
Priority changed from 4 to 3
resolution changed from Returned to Authors/Group to <None>
Jim Basney: 10/05/2005 1:15 PM EST
  Comment:
Here's an updated version of the document, reclassified as
Experimental.  I'll describe below how I've addressed David Snelling's
comments.  I've also made the following updates based on comments
from others:

  - Require support for SSL 3.0 and non-support for SSL 2.0.
  - Added reference to PKCS#10.
  - Added reference to [RFC3820] Section 3.4 for setting the proxy
    certificate subject.

> 1) I would like to know how many independent implementations there
>    are on MyProxy. As a non-WG submission, I feel this is and
>    exceptionally important issue.

See my earlier comment.

> 2) They need to reference RFC2119.

Added.

> 3) With respect to client authentication, they state it is OPTIONAL,
>    but require the the server support Proxies. This should be
>    conditional on the server requiring client
>    authentication. Otherwise it is contradictory.

Clarified that client authentication is REQUIRED for all commands
except 'Get', for which it is OPTIONAL.  Also changed proxy support to
SHOULD.

> 4) The zero byte to pander to a quirk in a proprietary protocol is a
>    non-sense. The WG should negotiate with the GSI implementers and
>    remove this meaningless part of the protocol. Basically it make
>    the GGF look sloppy.

I can't change the deployed protocol, but I removed the reference to
GSI here in hopes that it looks less sloppy.

> 5) Passwords of 8 characters and probably better.

Existing implementations require only 6 characters, so I kept that as
is.  The document says, "servers MAY optionally enforce additional
pass phrase quality policies."

> 6) They need to specify a maximum time for the life time. A
>    implementor of the current spec would need to implement arbitrary
>    precision integers to comply with the specification.

Added "not to exceed one billion seconds" which allows implementations
to use a 32 bit signed integer.

> 7) Is there an end of buffer marker or is it just EOI?

Each message is NULL-terminated.

> 8) With respect to the line order either the client's or the
>    server's obligations should be a MUST. The collection of SHOULDs
>    on both sides leaves an awkward gap.

Changed it to a MUST.

> 9) The Get command text should reference the Proxy RFC.

Done.
 
> 10) The Get command text states "pass phrase protecting the proxy
>     credential". Is it really a proxy credential or can it be a root
>     credential?

It can be a proxy or end entity credential.  I removed "proxy" here.

> 11) On Put again, I would prefer 8 charters.

See #5 above.

> 12) Again a maximum for the maximum is needed.

See #6 above.

> 13) Last paragraph of Put used the term 'delegated', which is never defined.

Removed "delegated".

> 14) In Info. This is the first specification and therefore the term
>     backward compatibility is not needed. The SHOULDs are OK.

Removed mention of backward compatibility.

> 15) The Info command implies that client authentication is
>     required. I would make this the case as a solution to 3. It is
>     very strange to define a specification that clearly allow one
>     it's operations to fail by definition in a fully compliant
>     specification.

Made client authentication required.

> 16) The description of the response suddenly became informal rather
>     than following the pattern of the earlier commands.

Changed it to match the other sections more closely.

Thanks,
Jim
  Action: Update
Jim Basney: 10/05/2005 1:15 PM EST
  Attachment: draft-ggf-basney-myproxy.doc (75.5 KB)
  Action: Update
File added set to 690: draft-ggf-basney-myproxy.doc
Dane Skow: 09/20/2005 4:54 PM EST
  Comment:
Since this document has sparked a great deal of discussion, I would like to add my comments to the record as the other AD for the relevant Area.

I concur with the decision to support advancement of this document as an experimental track document. This document records the specification of the 
protocol used by the MyProxy implementation of a credential repository. It is not presented as a recommendation for global standardization of 
credential repositories. This is consistent with the intent of the Experimental document track.

I believe it is a benefit to the community for GGF to accept individual submissions documenting details of such widely deployed software using the 
experimental or informational document tracks. Such publication indicates the document has passed a peer review for quality, but does not constitute a
 community recommendation.

Should a community of implementers form behind this protocol as a general credential repository protocol, then formation of a Working Group to develop
 and advance a recommendations track document reflecting the consensus would be appropriate.
  Action: Update
Greg Newby: 09/20/2005 10:25 AM EST
  Comment:
The GFSG had an extensive discussion concerning this document.
Overall, there is consensus that this document would be good
to add to the GGF document series, after working through
the public comment & review process.

Prior to moving to public comment, the GFSG would like to suggest
the comments in this tracker (by Snelling) be addressed.  This
will make the document better prepared for public comment.
Is this possible and reasonable, for some further revision (or, 
possible, discussion with Dave & others)?  Olle is also available
to talk about this document and its process, as am I.

The GFSG recommended this document be reclassified
as Experimental, rather than Recommendation.  Although
there is recognition that this document is about a specification,
that does not prevent it being in the Experimental track.  This
classification will allow further time to gain Working Group-style
consensus & technical discussion, perhaps moving to a follow-on
document in the future.  Yet, it will serve to get the document
published and "out there," as an aid to implementers and 
follow-on standards.  This is open to further discussion, if the
author (Jim) desires it.

Thanks again for this submission.
  Action: Update
Greg Newby: 09/20/2005 10:25 AM EST
  Action: Update
artifact_status changed from GFSG Review to Returned to Author(s)
Category changed from Recommendations Track to Experimental
resolution changed from <None> to Returned to Authors/Group
Jim Basney: 09/13/2005 10:44 AM EST
  Comment:
I'd like to provide some additional context for this submission.  At
the GGF12 Grid Security Area Meeting, Mike Helm requested that I
submit a specification for the MyProxy protocol to GGF, and there
seemed to be general agreement that this would be useful to the
community.  Dane and Olle told me I could email the specification to
them for submission and that a working group wasn't required to
document an existing protocol in use by the community.  My intention
is not to re-design the MyProxy protocol, but to document the protocol
as it is currently implemented (and used in a number of grids today)
to promote interoperability.  I'm willing to change the document from
recommendations track to whatever the GFSG thinks is most appropriate
for a document of this type.

I will attempt to address David Snelling's comments in an updated
draft.  Two of the comments I address directly below.

> 1) I would like to know how many independent implementations there
>    are on MyProxy. As a non-WG submission, I feel this is and
>    exceptionally important issue.

There's a C implementation (client and server) at
<http://myproxy.ncsa.uiuc.edu/>; and a Java implementation
(client-only) at <http://www.cogkit.org/>.  There are also Python and
Perl bindings available for the C client implementation at
<http://dsd.lbl.gov/gtg/projects/pyGlobus/>; and
<http://gridport.sourceforge.net/>.

> 4) The zero byte to pander to a quirk in a proprietary protocol is a
>    non-sense. The WG should negotiate with the GSI implementers and
>    remove this meaningless part of the protocol. Basically it make
>    the GGF look sloppy.

It's not desirable for us to change the GSI protocol at this stage or
to break backwards compatibility in a system we've had deployed for 5
years now.
  Action: Update
David Snelling: 09/07/2005 6:19 AM EST
  Comment:
Comments if 15 Day GSFG Review from Dave Snelling

1) I would like to know how many independent implementations there are on MyProxy. As a non-WG submission, I feel this is and exceptionally important 
issue.

2) They need to reference RFC2119.

3) With respect to client authentication, they state it is OPTIONAL, but require the the server support Proxies. This should be conditional on the 
server requiring client authentication. Otherwise it is contradictory.

4) The zero byte to pander to a quirk in a proprietary protocol is a non-sense. The WG should negotiate with the GSI implementers and remove this 
meaningless part of the protocol. Basically it make the GGF look sloppy.

5) Passwords of 8 characters and probably better.

6) They need to specify a maximum time for the life time. A implementor of the current spec would need to implement arbitrary precision integers to 
comply with the specification.

7) Is there an end of buffer marker or is it just EOI?

8) With respect to the line order either the client's or the server's obligations should be a MUST. The collection of SHOULDs on both sides leaves an 
awkward gap. 

9) The Get command text should reference the Proxy RFC.

10) The Get command text states "pass phrase protecting the proxy credential". Is it really a proxy credential or can it be a root credential?

11) On Put again, I would prefer 8 charters.

12) Again a maximum for the maximum is needed.

13) Last paragraph of Put used the term 'delegated', which is never defined.

14) In Info. This is the first specification and therefore the term backward compatibility is not needed. The SHOULDs are OK. 

15) The Info command implies that client authentication is required. I would make this the case as a solution to 3. It is very strange to define a 
specification that clearly allow one it's operations to fail by definition in a fully compliant specification.

16) The description of the response suddenly became informal rather than following the pattern of the earlier commands.

In summary, I feel it is clear that this spec has not been through a WG process. I would send it back to the author and encourage either a WG be 
formed or that the author seek a co-author willing to implement the protocol 100% independently. I would not pass this directly to Public Comment as a
 Recommendations document.
 
Dave
  Action: Update
Greg Newby: 08/30/2005 10:50 AM EST
  Comment:
Thanks for this submission.  As a recommendation track
document not coming from within a GGF working group
or research group, there are a few different options
on how to proceed.  (These procedures are in our GFD-C.1
document.)

My initial review of this document is favorable: it's concise,
nicely written, well formatted, and seems to be technically
astute.  Also, I believe it's useful and relevant to the GGF
community & mission.

Per Olle Mulmo's comment in this tracker, this document has
already been reviewed by, and is endorsed by, groups and 
area directors in the Security area.  Without this endorsement,
I would have sought one from the Security AD and/or
cognizant WG/RG chairs.  My understanding of our GFD-C.1
document is that the next step is to present this document
for 15-day GFSG review.  From there, the document might
be sent back to the authors for further work, moved to
public comment, rejected, reclassified, etc.

I'm asking Olle Mulmo to help shepherd this to the GFSG review.
Due from the GFSG Wednesday September 14 (or the GFSG conference
call right afterwards: Tuesday September 20)
  Action: Update
Greg Newby: 08/30/2005 10:50 AM EST
  Action: Update
artifact_status changed from Initial Editor Review to GFSG Review
assigned_to changed from 302 to 477
Priority changed from 5 to 4
resolution changed from Accepted to <None>
Greg Newby: 08/18/2005 1:03 PM EST
  Comment:
Dear Author or Draft Editor-

Thank you for submitting your draft to the GGF Editor!  In most cases the draft 
will be assigned to an Area Director for review as the first step in the document 
publication process.

The URL provided with this note allows you to track your submission and to 
communicate with the GGF Editor or Area Director(s) who are reviewing the 
draft.  At the very bottom of the tracker display (web page) a detailed log of all 
actions related to this submission is available.

You may also wish to alert your colleagues that the draft has been submitted, and from their GridForge accounts they may wish to monitor this item in 
order to receive email any time action is taken regarding this submission.

Informational and Experimental drafts are reviewed by the GGF Editor and one 
or more Area Directors.  The GGF Editor will determine whether the draft is 
ready for public comment, or if there are items for the author(s) to address 
prior to public comment.  This initial review generally takes no more than two 
weeks.

Community Practice and Recommendations Track drafts require a GFSG review 
prior to public comment.  This can add 2-3 weeks to the initial GGF Editor 
review depending on current workload of the GFSG.

Please do not hesitate to inquire about the status of your submission at any time by way of comments added to this tracker item, which will be 
automatically emailed to the individual who appears in the "assigned to" field.

Thanks very much- 
GGF Editor
  Action: Update
Greg Newby: 08/18/2005 1:03 PM EST
  Action: Update
artifact_status changed from Open to Initial Editor Review
Priority changed from - to 5
resolution changed from <None> to Accepted
Olle Mulmo: 08/16/2005 7:40 AM EST
  Comment:
The usefulness of this document has been discussed at Security Area meetings and on the security area mailing list. The submission in its current form
 has been read and is endorsed by the Security ADs.

This is a individual submission. My interpretation of GFD-1 is that this is OK any won't disqualify it from recommendations track.
  Action: Update
Olle Mulmo: 08/16/2005 7:34 AM EST
  Action: Create

Olle Mulmo: 08/16/2005 7:34 AM EST
  Attachment: draft-ggf-basney-myproxy.doc (75.5 KB)
  Action: Update
File added set to 665: draft-ggf-basney-myproxy.doc

 
 
 
< Previous
 
 
Next >
 


The Open Grid Forum Contact Webmaster | Report a problem | GridForge Help
This is a static archive of the previous Open Grid Forum GridForge content management system saved from host forge.ogf.org file /sf/sfmain/do/go/artf3461?nav=1&selectedTab=comments at Sun, 06 Nov 2022 08:41:34 GMT