[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: FW: Gen-art review of draft-ietf-netconf-beep-08.txt
Thanks for your responses.
Some further comments in line (especially in relation to PLAIN):
Regards,
Elwyn
Eliot Lear wrote:
Elwyn,
Thank you for your review. Please find my responses below.
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.
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.
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.
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.
Apparently it did not sufficiently confuse you. You understood what we
meant.
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 security considerations section specifies requirements and
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.
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.
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.
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.
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).
Yes. I would be happy to change the text to this if there are no
objections.
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.
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.
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.
Unless there is a specific security concern, I would rather not further
block this draft.
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.
Certificate management:
I was wondering whether some of the material from s5.2 of RFC3259
regardsing serverName etc could be usefully repeated here?
Could you please be more specific as to how?
Sorry this was a typo: I meant RFC3529!
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.
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.
s2.4, Locks:
A pointer to the relevant section of ref [1] talking about locks would
be helpful
The reader is presumed to be familiar with the core specification.
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.
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 ;-)
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.
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: s/transportlayer/transport layer/
s1.1: Expand CLI acronym.
I believe this is a well understood acronym.
s2.2, para 1: s/new channel/a new channel/
s2.3: s/<rpc> tag/<rpc> element/ (?)
Thank you again,
Eliot
--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>