Subject: Re: [Netconf] FW: WG Last Call for draft-ietf-netconf-rfc5539bis-07

From: t.petch <[email-masked]>
Date: Wed, 4 Feb 2015 11:09:38 +0000

I think that with the removal of the reference to server model, then the
steps in section 7 become hard to follow, almost incomprehensible - they
presume an information model which is not specified. I think that
Martin's comments revolved around this issue and that it is
insufficiently resolved.  So I would rewrite section 7, not changing the
meaning one iota (well, if I have, then I think the section must be
incomprehensible:-)

OLD
 o  The server maintains an ordered list of mappings of certificates
      to NETCONF usernames.  The username is derived by considering each
      list entry in order.  The fingerprint member of a list entry
      determines whether the list entry is a match:

      1.  If the list entry's fingerprint value matches that of the
          presented certificate, then consider the list entry as a
          successful match.

      2.  If the list entry's fingerprint value matches that of a
          locally held copy of a trusted CA certificate, and that CA
          certificate was part of the CA certificate chain to the
          presented certificate, then consider the list entry as a
          successful match.

   o  Once a matching list entry has been found, the mapping type
      property of the list entry is used to determine how the username
      associated with the certificate should be determined.  Possible
      mapping options are:

      A.  The username is explicitly configured.

      B.  The subjectAltName's rfc822Name is mapped to a username.

      C.  The subjectAltName's dNSName is mapped to a username.

      D.  The subjectAltName's iPAddress is mapped to a username.

      E.  Any of the subjectAltName's rfc822Name, dNSName, iPAddress is
          mapped to a username.

      F.  The certificate's CommonName is mapped to a username.

   o  If it is impossible to determine a username from the list entry's
      data combined with the data presented in the certificate, then
      additional list entries MUST be searched looking for another
      potential match.  Similarily, if the username does not comply to
      the NETCONF requirements on usernames [RFC6241] (i.e., the
      username is not representable in XML), then additional list
      entries MUST be searched looking for another potential match.  If
      there are no further list entries, the TLS session MUST be
      terminated.

NEW

 o  The server maintains an ordered list, with each entry containing a
certificate fingerprint, a NETCONF username and, optionally, one or more
fields that may appear in the certificate, namely the rfc822Name,
dNSName or iPAddress as they appear in the subjectAltName field,  or the
commonName [X520CommonName?] .

The username is derived by considering each  list entry in order.  If
the list entry matches the presented certificate, then further checks
are carried out based on the list entry.  If these result in an
acceptable username, then the search terminates.  If the username is not
acceptable, then the search continues with the next list entry.   If
there are no further list entries, the TLS session MUST be terminated.

The test for a matching certificate  is as follows.

      1.  If the fingerprint value of the list entry matches the
fingerprint of the
          presented certificate, then consider the list entry as a
          successful match.

      2.  If the fingerprint value of the list entry matches that of a
          locally held copy of a trusted CA certificate, and that CA
          certificate was part of the CA certificate chain to the
          presented certificate, then consider the list entry as a
          successful match.

Once a matching list entry has been found, the list entry is considered
further.  If the username does not comply to the NETCONF requirements on
usernames [RFC6241] (i.e., the username is not representable in XML),
then the username is not acceptable and list entries MUST be searched
looking for another certificate match.

      A.  If the list entry contains just a compliant username, then
that username is used.

      B.  If the list entry contains just an rfc822Name which matches
that in the matched certificate, then the username from the list entry
is used..

      C.  If the list entry contains just a dNSName which matches that
in the matched certificate, then the username from the list entry is
used..

      D.  If the list entry contains just an iPAddress which matches
that in the matched certificate, then the username from the list entry
is used..
.
      E.  If the list entry contains more than one of rfc822Name,
dNSName and iPAddress, and one or more of them match the corresponding
fields in the matched certificate, then the username from the list entry
is used..

[What happens if e.g. the dNSName matches but the rfc822Name does not?
Needs clarifying IMO]

      F.  If the commonName matches that in the matched certificate,
then the username from the list entry is used..

      G. If none of the steps above yield an acceptable username, then
additional list entries MUST be searched looking for a further
certificate match.

Tom Petch

----- Original Message -----
From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
To: <[email-masked]>
Sent: Friday, January 30, 2015 2:17 PM
Subject: [Netconf] FW: WG Last Call for draft-ietf-netconf-rfc5539bis-07

> Dear NETCONF WG,
>
> we think the WGLC of the draft-ietf-netconf-rfc5539bis was successful
> with useful comments and discussion. Based on the WGLC result Juergen
> provided draft-ietf-netconf-rfc5539bis-08.
>
> See http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-08
>
http://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf-rfc5539bis-08.txt
>
> Please look at v08 of the draft and let the co-chairs know by February
4,
> 2015 EOB PT, whether you have any objections to starting the
publications
> process and asking our AD Benoit Claise to do his review.
>
> Best Regards,
> Mehmet and Mahesh
>
>
> -----Original Message-----
> From: ext Juergen Schoenwaelder
[mailto:[email-masked]]
> Sent: Tuesday, January 27, 2015 8:24 AM
> To: Ersue, Mehmet (NSN - DE/Munich)
> Cc: [email-masked]
> Subject: Re: [Netconf] WG Last Call for
draft-ietf-netconf-rfc5539bis-07
>
> On Mon, Jan 05, 2015 at 08:46:09PM +0000, Ersue, Mehmet (NSN -
DE/Munich) wrote:
> > Dear NETCONF Members,
> >
> > we hereby issue a WG Last Call for draft-ietf-netconf-rfc5539bis-07.
> >
> > The document can be found at:
> >     http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-07
> >
> > Please review and send your comments to the WG mailing list by
January 19, 2015 EOB PT.
> >
>
> Mehmet and Mahesh,
>
> I have posted draft-ietf-netconf-rfc5539bis-08 which I believe
> addresses the WG last call comments. Please check and if you agree,
> please produce a document writeup and move the I-D over to the IESG.
>
> /js
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
>
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 9 Feb 2015 18:01:19 +0100

Hi,

apparently the text is not clear enough since your interpretation
seems to be somewhat incorrect. Does the attached rfcdiff resolve the
issue?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: t.petch <[email-masked]>
Date: Wed, 11 Feb 2015 12:15:37 +0000

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "t. petch" <[email-masked]>
Sent: Monday, February 09, 2015 5:01 PM

> seems to be somewhat incorrect. Does the attached rfcdiff resolve the

Yes, my interpretation was incorrect and this is clearer but I am still
left uncertain over steps A to F when they say e.g.

D. The subjectAltName's iPAddress is mapped to the username
   (map type 'san-ip-address').

How is it mapped?  I assume that an iPAddress cannot be a username per
se(!) so I imagine that there needs to be a data structure with a list
of iPAddress and corresponding username. Since -08 only mentioned the
one data structure, I rolled everything into that data structure.  Your
rewording leads me to create a second data structure mapping the various
fields from the certificate to a username.  If so, I think that this is
worth a mention under a).

A minor comment; I would prefer a consistent identifier for 'map type',
such as 'map type' - currently, you have 'mapping type', 'mapping type
property' and 'map type',

Tom Petch

terminated.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 12 Feb 2015 08:42:40 +0100

Hi,

here is another attempt, incorporating more text from the RFCs that
originally defined this algorithm.

/js

---

From: t.petch <[email-masked]>
Date: Thu, 12 Feb 2015 11:59:21 +0000

Juergen

Yes, I now appreciate the depths of my original misunderstanding!
Looks good.

(As you may have guessed, I consciously did not look at anything that
was not a Normative Reference so as not to know more that a reader might
be expected to know).

Perhaps
/explicitely/explicitly/

Tom Petch

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "t. petch" <[email-masked]>
Cc: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>;
<[email-masked]>
Sent: Thursday, February 12, 2015 7:42 AM
Subject: Re: [Netconf] FW: WG Last Call for
draft-ietf-netconf-rfc5539bis-07

> > > > I think that with the removal of the reference to server model,
then
> > the
> > > > steps in section 7 become hard to follow, almost
incomprehensible -
> > they
> > > > insufficiently resolved.  So I would rewrite section 7, not
changing
> > the
> > > >       to NETCONF usernames.  The username is derived by
considering
> > each
> > > >       E.  Any of the subjectAltName's rfc822Name, dNSName,
iPAddress
> > is
> > > >       potential match.  Similarily, if the username does not
comply
> > to
> > > >       entries MUST be searched looking for another potential
match.
> > If
> > > >  o  The server maintains an ordered list, with each entry
containing
> > a
> > > > certificate fingerprint, a NETCONF username and, optionally, one
or
> > more
> > > > dNSName or iPAddress as they appear in the subjectAltName field,
or
> > the
> > > > The username is derived by considering each  list entry in
order.
> > If
> > > > acceptable username, then the search terminates.  If the
username is
> > not
> > > >       2.  If the fingerprint value of the list entry matches
that of
> > a
> > > >       C.  If the list entry contains just a dNSName which
matches
> > that
> > > > fields in the matched certificate, then the username from the
list
> > entry
> > > > is used..
> > > >
> > > > [What happens if e.g. the dNSName matches but the rfc822Name
does
> > not?
> > > >       G. If none of the steps above yield an acceptable
username,
> > then
> > > > > See
http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-08

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 12 Feb 2015 13:23:34 +0100

Mehmet,

shall I post -09 and what is the next step then?

/js

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 12 Feb 2015 15:30:36 +0000

Hi Juergen,

please do upload -09 after this final agreement.

We need to give the WG at least 3-4 days to comment on -09 before 
asking our AD for review and starting the IESG process.

Cheers, 
Mehmet 

-----Original Message-----
From: ext Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Thursday, February 12, 2015 1:24 PM
To: Ersue, Mehmet (NSN - DE/Munich)
Cc: t. petch; [email-masked]
Subject: Re: [Netconf] FW: WG Last Call for draft-ietf-netconf-rfc5539bis-07

Mehmet,

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 12 Feb 2015 17:00:02 +0100

> please do upload -09 after this final agreement.

done
 
> asking our AD for review and starting the IESG process.

ack

/js

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 12 Feb 2015 16:07:11 +0000

All,

after solving the last remaining issue please look at -09 and comment within 4 business days before we go to AD review and initiate the publication process.
The deadline for comments is February 18, 5pm CET.

https://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-09
https://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf-rfc5539bis-09.txt 

Regards, 
Mehmet 

-----Original Message-----
From: ext Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Thursday, February 12, 2015 5:00 PM
To: Ersue, Mehmet (NSN - DE/Munich)
Cc: [email-masked]
Subject: Re: [Netconf] FW: WG Last Call for draft-ietf-netconf-rfc5539bis-07

done

ack

/js