Re: I-D Action: draft-joseph-pkix-p6rsshextension-03.txt

<inline, on my preliminary comments>

Tom Petch


----- Original Message -----
From: "Mark Joseph" <[email protected]>
To: "t.petch" <[email protected]>; "Sean Turner" <[email protected]>;
<[email protected]>;
<[email protected]>
Sent: Thursday, September 05, 2013 2:01 AM
From: t.petch [mailto:[email protected]]
To: Sean Turner [mailto:[email protected]], [email protected],
[email protected]
Sent: Tue, 03 Sep 2013 10:13:20 -0800
A brief look makes me think that more work i needed.

   - Certifcate sometimes has two i, sometimes one i

  Sorry but this is not clear, can you please explain.
<tp>

3.1 SSH_PUBLICKEY_CERTIFCATE_ALREADY_PRESENT
4.1 SSH_PUBLICKEY_CERTIFICATE_ALREADY_PRESENT.
e,g,


   - why list-certificates with a  hyphen and listnamespaces without?

  Yes we could make that change thought I don't see how it is really
significant.

<tp>
the presence and absence of the hyphen will just cause coders, users and
everyone else to make mistakes, forgetting that it is sometimes there
and sometimes not.  Technically it makes no difference; in terms of
producing a robust protocol, it does

   -" This document defines version 3 of the new protocol.  We are using
     version 3 so that it can be backward compatible with the protocol
     defined by RFC 4819 [1]. "
    Um, seems a bit like namespace squatting which seems improper in an
  Informational RFC

Our document actually defines a totally separate protocol from RFC 4819.
In section 3 of our document we state that we use a different subsystem
name:

"[email protected]".    We can start the version number at
anything.   The benefit of starting with Version 3 is that software
used to build RFC 4819 implemenations could be extended easily
to add the functionality we have defined (since that is what we did).

<tp>
The IETF has produced a Standards Track V2 - I expect the numbers 3, 4,
5 etc to be implicitly at least reserved for IETF Standard Track use,
not to be used for a private protocol, even if it does appear in an RFC.
And since it is 'totally separate', then the use of 3 seems
inappropriate.  With other, more recent protocols, fields like this have
a defined range for IETF Standards and a separate one for other
variants.

  - " Examples of possible "certificate format name" are: "X509",
     "pgp-sign-rsa", and "pgp-sign-dss".  "
  I would expect interoperability to require a defined list, the sort of
  thing that IANA does rather well.
  Also, the names would be more recognisable if there were something
that
  said certificate, rather than key types, eg cert-pgp-sign-rsa
A previous reviewer had us add the PGP reference since it comes from RFC
4253 SSH Transport layer
protocol (Section 6 Public Key Algorithms).  Frankly I don't see the
benefit of doing an IANA of certificate types
for this RFC since there has to be an existing one already for X509 and
PGP certs.  Seems redundant.

<tp>
I am surprised by this.  Interoperability, which is a usual requirement
for an IETF protocol, requires that different implementors come up with
solutions that can interwork, which means that they know what values of
what parameters may be encountered, and what they mean.  An undefined
list of potential certificate types seems not to meet that requirement.


  - what happens if a removed certificate is in use? I am used to key
  replacement protocols that have well-defined procedures about what
  overlap there is and how it is managed.  A bald replace seems dodgy.

 In reality, systems will use a key or cert for an existing session even
if it gets
deleted since it has already been loaded into the protocol software
(e.g., openSSL)
 Any new session that tries to use the key or cert while it is being
changed should not be able to.
This is am implementation on the server side and not appropriate for a
protocol definition.
If we add that it cannot be deleted while in use then likely it can be
held far longer
than desired.   An administrator who wants or even needs to remove a
cert should
be able to do so immediately for all new sessions.

<tp>
I find the Security Considerations weak, by the standards of 2013, and
this is an area which I think that they should explore, pointing out the
dangers.

  - is there any constraint about the relationship between a certificate
  and the one that is replacing it? should the new one have anything in
  common with the old, should it be more secure for some meaning of that
  term?  To me, managing certificates should be more heavyweight than
  managing public keys.

  Interesting point but I don't see the relevance to this work.   All we
are describing
is a mechanism to modify both keys and certificates.   What you mention
seems like
a discussion of what sits on top of our mechanism.   If you look at KMIP
the server
can define policies and yet KMIP is a much more than what we describe.

<tp>
I find the Security Considerations weak, by the standards of 2013, and
this is an area which I think that they should explore, pointing out the
dangers.
Certificates are the crux of much security so replacing one by another
seems like replacing the foundation stone of a building and whilst you
may only be manufacturing the crowbar that makes this possible, I think
that, in these times, it behoves you to point out that doing so may
cause the building to collapase on you.

 Tom Petch


  ----- Original Message -----
  From: "Sean Turner" <[email protected]>
  To: <[email protected]>;
  <[email protected]>
  Sent: Tuesday, September 03, 2013 2:57 PM
  Subject: Fwd: I-D Action: draft-joseph-pkix-p6rsshextension-03.txt

  > This draft is going to be on an upcoming IESG telechat (as an ISE
  > submission) and was wondering if somebody could have a look at it
and
  > provide comments.
  >
  > Thanks,
  >
  > spt
  >
  > -------- Original Message --------
  > Subject: I-D Action: draft-joseph-pkix-p6rsshextension-03.txt
  > Date: Sun, 23 Jun 2013 11:27:34 -0700
  > From: [email protected]
  > Reply-To: [email protected]
  > To: [email protected]
  >
  >
  > A New Internet-Draft is available from the on-line Internet-Drafts
  > directories.
  >
  >
  > Title           : P6R's Secure Shell Public Key Subsystem
  > Author(s)       : Mark Joseph
  >                            Jim Susoy
  > Filename        : draft-joseph-pkix-p6rsshextension-03.txt
  > Pages           : 10
  > Date            : 2013-06-23
  >
  > Abstract:
  >     The Secure Shell Public Key Subsystem protocol defines a key
  > distribution
  >     protocol to provision an SSH server with user's public keys.
  However,
  >     that protocol is limited to provisioning an SSH server.   This
  document
  >     describes a new protocol that builds on the protocol defined in
  RFC 4819
  >     to allow the provisioning of keys and certificates to a server
  using the
  >     SSH transport.
  >
  >     The new protocol allows the calling client to organize
  >     keys and certificates in different namespaces on a server.
These
  >     namespaces can be used by the server to allow a client to
  configure
  >     any application running on the server (e.g., SSH, KMIP, SNMP).
  >
  >     The new protocol provides a server-independent mechanism for
  clients
  >     to add public keys, remove public keys, add certificates, remove
  >     certificates, and list the current set of keys and certificates
  known by
  >     the server by namespace (e.g., list all public keys in the SSH
  >     namespace).
  >
  >     Rights to manage keys and certificates in a specific namespace
are
  >     specific and limited to the authorized user and are defined as
  part of
  >     the server's implementation.   The described protocol is
backward
  >     compatible to version 2 defined by RFC 4819.
  >
  >
  >
  > The IETF datatracker status page for this draft is:
  > https://datatracker.ietf.org/doc/draft-joseph-pkix-p6rsshextension
  >
  > There's also a htmlized version available at:
  > http://tools.ietf.org/html/draft-joseph-pkix-p6rsshextension-03
  >
  > A diff from the previous version is available at:
  >
http://www.ietf.org/rfcdiff?url2=draft-joseph-pkix-p6rsshextension-03
  >
  >
  > Internet-Drafts are also available by anonymous FTP at:
  > ftp://ftp.ietf.org/internet-drafts/
  >
  > _______________________________________________
  > I-D-Announce mailing list
  > [email protected]
  > https://www.ietf.org/mailman/listinfo/i-d-announce
  > Internet-Draft directories: http://www.ietf.org/shadow.html
  > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt