Subject: FW: Gen-art review of draft-ietf-netconf-beep-08.txt

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Wed, 1 Mar 2006 12:29:04 +0100

Not sure how much of this (if any) will make it into a DISCUSS,
but since (I believe) Eliot is in Europ, I decided to forward
rigth away, so Eliot can check and respond. Pls copy IESG
on your response (unless you just want to check with the WG
first). I did not analyze these comments yet myself, they
just came in.

Bert

-----Original Message-----
From: Elwyn Davies [mailto:[email-masked]]
Sent: Wednesday, March 01, 2006 12:05
To: [email-masked]
Cc: Mary Barnes; Wijnen, Bert (Bert)
Subject: Gen-art review of draft-ietf-netconf-beep-08.txt

I was selected as General Area Review Team reviewer for this specification
(for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Document: draft-ietf-netconf-beep-08.txt
Intended Status: Proposed Standard (WG submission)
Shepherding AD: Bert Wijnen
Review Trigger: IESG Telechat 2 March 2006

Summary:
This document is not ready for PS.

There is a considerable lack of clarity in mapping the requirements and 
roles between the various protocols which are being combined in this 
protocol, and the manager/agent terminology used has been eschewed by 
NETCONF in favour of client/server.  If used at all manager/agent 
terminology should be confined to the 'reversability' motivation in the 
introduction.

The emphasis on reversability may be confusing: Checking with the 
NETCONF protocol, if I understand correctly, a given endpoint in a 
session is confined to being a client or a server.  Thus although a BEEP 
channel is reversible the NETCONF session that runs over it is not and 
indeed the transport protocol has to tell NETCONF which sort of endpoint 
(client or server) it is.

The security considerations section specifies requirements and 
operations rather than just discussing the threats and their mitigation.

Review:

Endpoint roles:
There are three pairs of terms in use in the draft for the roles of the 
two ends of the conversation:
1. manager and agent (sort of implicitly how NETCONF would use the profile)
2. listener and initiator (BEEP)
3. client and server (TLS)
The mapping between the terms in 1 and 2 is apparently explained in s2.1 
but this explanation is not really a complete reflection of the 
situation explained in the BEEP RFC: ie the client/server terminology 
for the initial setup followed by the listener/initiator terminology for 
subsequent exchanges. In turn the mapping between 2 and 3 is not made 
explicit - I thought I could guess but after reflection I am not 
absolutely sure and it would be sensible to make it absolutely clear.

However NETCONF does not talk about managers and agents but about 
clients and servers, and BEEP also talks about clients and servers after 
the channel is set up. So we really ought to be talking about four pairs 
of roles and how they interrelate:
1. NETCONF client and server (this is what the profile has to support)
2. BEEP listener and initiator (setting up a channel from either end)
3. BEEP client and server (mapping to NETCONF and emphasising that it is 
not tied to listener/initiator roles)
4. TLS client and server (not sure which way round this is supposed to map)

I don't think the document overall expresses what needs to be said here 
and also doesn't give the semantics to express which way round the 
eventual NETCONF client/server connection is going to be setup.

Message and object conventions:
BEEP messages vs XML objects:
Much as I like to see the proper pleasantries being exchanged before the 
manager and agent get down to business, I think that when para 1 of s2.1 
says 'greetings are exchanged' I think it means '(BEEP) Greeting 
messages are exchanged' (2 places).

In para 5 of s2.1 we then have 'in the first BEEP <greeting>'.  This 
presumably means in the first Greeting message but it could also be 
talking about the <greeting> element in that message - this is a bit 
confusing unless you are very familiar with BEEP.  I think it would be 
best to say 'in the first BEEP Greeting message' here, or alternatively 
'in the <greeting> element of the first BEEP Greeting message.

Version of SASL PLAIN to be used:
This specification refers to RFC2595 but the SASL PLAIN mechanism is 
currently under revision (see draft-ietf-sasl-plain-08.txt).  Should 
this (new) specification be using the new PLAIN specification? The 
latter part of para 5 of s2.1 seems a bit garbled and tautologous - 
rework needed.

Certificate management:
I was wondering whether some of the material from s5.2 of RFC3259 
regardsing serverName etc could be usefully repeated here?

Channels:
If I understand correctly, everything in s2.1 leads to the first BEEP 
channel (channel 0) being established between a pair of elements.  I 
think it would be good to mention channel 0 here because otherwise it 
makes its first appearance in s2.4 when it is being closed.

Extra channels:
>
>    Certain NETCONF capabilities may require additional BEEP channels.
>    When such capabilities are defined, a BEEP mapping must be defined 
> as well
>
The phraseology used here doesn't make it very clear if this is about 
possible future extensions or something that already exists.  If some do 
exist it would be good to give an example.  I am not sure how the second 
sentence ties in with the original statement in the abstract i.e. that 
this document *is* the BEEP mapping for NETCONF!  This probably ought to 
go in a separate extensibility section.

s2.4, Locks:
A pointer to the relevant section of ref [1] talking about locks would 
be helpful

s3, requirements:
The material after the second sentence of the second paragraph is about 
requirements and specification of how TLS and SASL are  to be used.  
This doesn't belong here.  It should all be specified before we get to 
this section.  It should probably make it clear that TLS is recommended 
rather than mandatory.

Editorial nits:
[Abstract: I take it from draft-netconf-prot that NETCONF is not an 
acronym.]

BEEP messages: It doesn't desperately matter but are the message 
character counts right?  I wasn't sufficiently anally retentive to check 
them.

s1.1: s/transportlayer/transport layer/
s1.1: Expand CLI acronym.

s2.2, para 1: s/new channel/a new channel/

s2.3: s/<rpc> tag/<rpc> element/ (?)

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Eliot Lear <[email-masked]>
Date: Wed, 01 Mar 2006 14:34:12 +0100

Elwyn,

Thank you for your review.  Please find my responses below.
> terminology should be confined to the 'reversability' motivation in the 

In the community we find ourselves, manager and agent are well
understood terms.  Anyone who does not understand them is unlikely to
implement the protocol.  If there is a bug, it is in the base
specification in the use of the terms client and server, as they can be
overloaded beyond recognition.

> (client or server) it is.
Apparently it did not sufficiently confuse you.  You understood what we
meant.
> operations rather than just discussing the threats and their mitigation.

The security considerations section should be viewed in the context of
the base protocol.  I will not reiterate everything said there.

> eventual NETCONF client/server connection is going to be setup.

I have proposed a change to the mapping to address this point, but
ultimately it has boiled down to this: a manager knows its a manager and
an agent knows its an agent.  As it says in the draft at the end of
section 2.1:

  We now distinguish between manager  and agent, and it is assumed that
each knows its role in the
  conversation.

I would still prefer to have agent and manager profile roles, but that
was not the working group's choice.
> messages are exchanged' (2 places).
Yes.  I would be happy to change the text to this if there are no
objections.
> 'in the <greeting> element of the first BEEP Greeting message.
This is in the context of the SASL and TLS profiles.  Profiles in BEEP
are only advertised in the <greeting> section.  The reader is assumed to
be familiar with RFCs 3080 and 3081.
> latter part of para 5 of s2.1 seems a bit garbled and tautologous - 

Unless there is a specific security concern, I would rather not further
block this draft.
> regardsing serverName etc could be usefully repeated here?

Could you please be more specific as to how?
> go in a separate extensibility section.
I would be happy to change the text to indicate that new capabilities
that make use of additional channels will require an update to this
mapping specification.
> A pointer to the relevant section of ref [1] talking about locks would 
The reader is presumed to be familiar with the core specification.
> this section.  
I would be happy to move this text forward to discussion of the two
profiles.
> It should probably make it clear that TLS is recommended 
> rather than mandatory.
>   
I believe that is already clear as my use of "ifs" in this document
exceeded my "if" quota ;-)
> character counts right?  I wasn't sufficiently anally retentive to check 
If there is one thing more you or others could check I wish it would be
this.  I believe I was careful to count characters in each example,.

> s1.1: Expand CLI acronym.
I believe this is a well understood acronym.
> s2.3: s/<rpc> tag/<rpc> element/ (?)

Thank you again,

Eliot

---

From: Elwyn Davies <[email-masked]>
Date: Wed, 01 Mar 2006 17:54:04 +0000

Thanks for your responses.

Some further comments in line (especially in relation to PLAIN):

Regards,
Elwyn

> overloaded beyond recognition.
Indeed: for those of us introduced to SNMP at a tender age, manager and 
agent come naturally, but this is a mapping to NETCONF and for better or 
for worse the NETCONF WG has decided on client and server so I think 
this spec has to be couched in those terms.
> Apparently it did not sufficiently confuse you.  You understood what we
BUT only after spending a couple of hours digging into BEEP, NETCONF and 
TLS, and asking a friend.   The point is that the reversibility applies 
to who can start the connection but once NETCONF gets going a given 
channel is not reversible: getting this from the specification was not 
so easy.
> the base protocol.  I will not reiterate everything said there.
That is not what I am asking for.  The whole business of managing 
certificates and what profiles are advertised are parts of the 
functionality that have to be implemented.  Looking inside the security 
considerations for this is not something that I would hope to have to do.
> Unless there is a specific security concern, I would rather not further
I noticed that Russ Housley has raised a DISCUSS in relation to the use 
of simple identity certificates for clients.  Your comment prompted me 
to go and look at what the update of PLAIN was doing and as a result I read:
>    When the PLAIN mechanism is used, the server gains the ability to
>    impersonate the user to all services with the same password
>    regardless of any encryption provided by TLS or other network privacy
>    mechanisms.  While many other authentication mechanisms have similar
>    weaknesses, stronger SASL mechanisms such as Kerberos address this
>    issue.  Clients are encouraged to have an operational mode where all
>    mechanisms which are likely to reveal the user's password to the
>    server are disabled.
>   
It occurs to me that the combination of the reversibility of BEEP, PLAIN 
and simple identity certificates is possibly a serious security risk. I 
am not a security expert but I think I could envisage an attack as follows:
The attacker impersonates a server (agent) using a simple identity 
certificate and captures the password  supplied by the client. It then 
turns round and using the password and the same certificate impersonates 
a client (manager) to a different, real server (agent).
Consequently it is not only the client end that needs more specificity 
in its certificate but also the server end.

> Could you please be more specific as to how?
Sorry this was a typo: I meant RFC3529!

---

From: Eliot Lear <[email-masked]>
Date: Fri, 03 Mar 2006 09:32:38 +0100

Elwyn,

More discussion below.
 
> Indeed: for those of us introduced to SNMP at a tender age, manager
> and agent come naturally, but this is a mapping to NETCONF and for
> better or for worse the NETCONF WG has decided on client and server so
> I think this spec has to be couched in those terms.
If this were a small amount of work, I wouldn't argue the point.  It's a
large amount of work to rework the draft for all of that, and BEEP
specifically avoids the use of client/server terms.  This having been
said, let me propose the following wording be added as follows:

NEW S2P2:

    For purposes of this document a manager is a NETCONF client, and an
    agent is a NETCONF server.  Use of client/server language in BEEP is
    avoided because of the common notion that in networking clients
    connect to servers.

>>> session is confined to being a client or a server.  Thus although a
>>> BEEP channel is reversible the NETCONF session that runs over it is
>>> not and indeed the transport protocol has to tell NETCONF which sort
>>> of endpoint (client or server) it is.
>>>       
> BUT only after spending a couple of hours digging into BEEP, NETCONF
> and TLS, and asking a friend.   The point is that the reversibility
> applies to who can start the connection but once NETCONF gets going a
> given channel is not reversible: getting this from the specification
> was not so easy.
With the added text I sent previously I believe this problem is now
resolved.
> functionality that have to be implemented.  Looking inside the
> security considerations for this is not something that I would hope to
> have to do.
I believe I addressed this concern below.
>>> Much as I like to see the proper pleasantries being exchanged before
>>> the manager and agent get down to business, I think that when para 1
>>> of s2.1 says 'greetings are exchanged' I think it means '(BEEP)
>>> Greeting messages are exchanged' (2 places).
>>>       

To be clear:

Section 2.1p1:

OLD:
  greetings are exchanged, they SHOULD each announce their support for

NEW:
  BEEP greeting messages are exchanged, they SHOULD each announce their
support for

And Section 2.1p2:

OLD:
  Once TLS has been started, a new greeting is sent by both initiator

NEW:
  Once TLS has been started, a new BEEP greeting message is sent by both
initiator

>>> confusing unless you are very familiar with BEEP.  I think it would
>>> be best to say 'in the first BEEP Greeting message' here, or
>>> alternatively 'in the <greeting> element of the first BEEP Greeting
>>> message.
>>>       
> I noticed that Russ Housley has raised a DISCUSS in relation to the
> use of simple identity certificates for clients.  Your comment
> prompted me to go and look at what the update of PLAIN was doing and
> as a result I read:
> It occurs to me that the combination of the reversibility of BEEP,
> PLAIN and simple identity certificates is possibly a serious security
> risk. I am not a security expert but I think I could envisage an
> attack as follows:
> turns round and using the password and the same certificate
> impersonates a client (manager) to a different, real server (agent).

Server-side certs are not subject to which role is played.  The draft
makes this clear.

> Sorry this was a typo: I meant RFC3529!
If I understand the discussion in RFC-3529 they are virtualizing the
service.  While I have no objection in principle, I'd suggest that is a
bit of an extension and not something that need be dealt with in the
first version of the standard.  Again, I would agree that it is a good
subject for future work.

>>> Channels:
>>> If I understand correctly, everything in s2.1 leads to the first
>>> BEEP channel (channel 0) being established between a pair of
>>> elements.  I think it would be good to mention channel 0 here
>>> because otherwise it makes its first appearance in s2.4 when it is
>>> being closed.
>>>
>>> Extra channels:
>>>      
>>>>    When such capabilities are defined, a BEEP mapping must be
>>>> defined as well
>>>>
>>>>           
>>> The phraseology used here doesn't make it very clear if this is
>>> about possible future extensions or something that already exists. 
>>> If some do exist it would be good to give an example.  I am not sure
>>> how the second sentence ties in with the original statement in the
>>> abstract i.e. that this document *is* the BEEP mapping for NETCONF! 
>>> This probably ought to go in a separate extensibility section.
>>>       
Section 2.2 second to last paragraph:

OLD:

NEW:

  Future NETCONF capabilities may require additional BEEP channels.

>>  
>>> s2.4, Locks:
>>> A pointer to the relevant section of ref [1] talking about locks
>>> would be helpful
>>>       
>>> The material after the second sentence of the second paragraph is
>>> about requirements and specification of how TLS and SASL are  to be
>>> used.  This doesn't belong here.  It should all be specified before
>>> we get to this section.      

I see that there already exists a forward reference already in the text
in S2.1p5.  I hope this would suffice.

Thank you again,

Eliot

---

From: Ted Goddard <[email-masked]>
Date: Fri, 3 Mar 2006 08:57:44 -0700

I intend to prepare the update draft-ietf-netconf-soap-08.txt as
follows;  are there any additional comments?

4.1  Integrity, Privacy, and Authentication

    The NETCONF SOAP binding relies on an underlying secure transport  
for
    integrity and privacy.  Such transports are expected to include TLS
    [9] (which, when combined with HTTP, is referred to as HTTPS) and
    IPsec.  There are a number of options for authentication (some of
    which are deployment-specific):

    o  within the transport (such as with TLS client certificates)

    o  within HTTP (such as Digest Access Authentication [7])

    o  within SOAP (such as a digital signature in the header [17])

    HTTP, BEEP, and SOAP level authentication can be integrated with
    RADIUS [10] (Remote Authentication Dial In User Service) to support
    remote authentication databases.

    At a miniumum, all conforming NETCONF over SOAP implementations MUST
    support TLS.  Specifically, NETCONF over SOAP over HTTP MUST support
    NETCONF over SOAP over HTTPS, and NETCONF over SOAP over BEEP MUST
    support NETCONF over SOAP over BEEP over TLS.

...

    [7]   Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P.,
          Luotonen, A., Sink, E., and L. Stewart, "HTTP Authentication:
          Basic and Digest Access Authentication", RFC 2617, June 1999,
          <http://www.ietf.org/rfc/rfc2617.txt>.

Thanks,
Ted.