Subject: [Gen-art] Gen-ART Last Call review of draft-ietf-rserpool-threats-09

From: Ben Campbell <[email-masked]>
Date: Tue, 8 Apr 2008 16:31:33 -0500

(Oops, sent from wrong account--sorry for the repeat.)

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

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-rserpool-threats-09
Reviewer: Ben Campbell	
Review Date:  2008-04-08
IETF LC End Date: 2008-04-14
IESG Telechat date: (if known)

Summary: This document is not ready for publication. It may or may not  
be on the right track, depending on the answer to my first comment.

Comments:

--General:

It is not clear to me what this draft seeks to accomplish. Without  
being an expert in RSerPool, it is not clear to me if the draft  
intends to offer requirements for new security mechanisms into the  
RSerPool protocol itself, or to offer guidance to implementors on how  
to securely implement the protocol.

If the former, then it is vague in many places, but is probably on the  
right track. However, would this mean that the other rserpool  
documents currently in last call will need significant changes  
indicated by _this_ draft? That is, if this draft progresses then the  
other are by definition not ready? (I fully admit not knowing the  
details of those drafts.)

If the latter, then it is not helpful in its current form, as the  
offered requirements say nothing about what mechanisms to use. I will  
offer more details below

The document does not use normative language, nor does it reference  
RFC 2119. I know normative language is not always required for  
informational RFCs, but it seems appropriate for this document, since  
it offers up important security requirements.

It seems like a lot of references are missing (e.g. ENRP, ASAP, etc.)

--Specific Comments:

Section 1:

The purpose of the draft is not clear from the introduction (See  
general comment above).

It would be nice to see a background paragraph describing what  
RSerPool is. There is a quick mention in the abstract, but the  
document should be "complete" without the abstract.

The introduction needs some references. (Actually, as far as I can  
tell the entire document is devoid of references.)

Section 1.1:

Definitions for "internal agent" and "external agent" would be helpful.

Section 2.1.2:

The first sentence is a sentence fragment. This occurs in many of the  
"Effect" sections--I am not going to repeat this comment each time,  
but please proofread for this. The RFC Editor will probably fix it,  
but it's always nice to save them work.

Section 2.2.2:

The attack is characterized as a DoS. The described attack allows data  
interception, which makes it a lot more than a DoS attack.

Section 2.3.2

s/hacker/attacker  (throughout the document.)

Section 2.3.3

This section needs more discussion. Is it possible for an  
authenticated PE to send misinformation about another PE? Is this also  
an authorization issue?

Section 2.4.3:

Authorized to do what? I can infer that from the previous section, but  
the requirement should be explicit.

Section 2.5.3

Is this really just an authentication issue? Is it enough to know the  
identities? Are there authorization decisions here?

Section 2.5.3: What does the attacker need to do to accomplish this  
attack?

Section 2.6.3

Is this advice to the implementor? If so, the document should describe  
what mechanism to use to authenticate the server. Or is the intent to  
say that the RSerPool protocol does not provide such a mechanism and  
needs to do so?

Section 2.8.3:

Same question about mechanism as in my previous comment.

Section 2.9.1:

I do not know the RSerPool details, but I would assume that if PE A  
could take over for PE B for a given user, the user would have to have  
the same trust relationship with PE B as for PE A. Is the point of  
this section to say that RSerPool does not require this and should?

Section 2.9.2:

The "Effect" section seems to simply restate the "Threat" section.  
What are the actual consequences of the attack?

Section 2.9.3:

Are you saying that RSerPool fails to give tools so that a user can  
establish the correct trust relationships with the new server when  
failing over and needs them? Or do you mean to say that implementation  
should use certain tools to do this? If the second, please call out  
the mechanism.

Section 2.10.1:

Is this one threat, or three different threats?

2.10.2:

What are the consequences of corrupt information in this case?

2.10.3:

Section needs more specifics. Which interfaces need integrity  
mechanisms? I can probably infer that from the Threat and Effect  
sections, but a "requirement" should state it explicitly.

2.12.-1 and 2.12.2:

The organization of these sections is confusing, and not consistent  
with that of the earlier sections. It is not clear to me how the  
effects line up with the threats. That is, is effect a. related to  
threat a., or is it related to all listed threats?

2.12.1 a.

How would the attacker do this? Does it require a MiTM?

2.12.1 c.

How does the attacker make such a claim?

2.12.3:

None of the attacks described in 2.12.* seem to be about  
confidentiality per se.

2.13.1:

s/"These messages"/"Endpoint unreachable messages"

Also, under what circumstances would a PU cause a message flood? Does  
the non-malicious case require an incorrect implementation?

2.13.2:

Section needs more detail? What service is denied, and to whom?

2.14.1:

s/"These Messages"/"Endpoint keep-alive messages"

Also, Is this not really the a consequence of 2.13, rather than a  
separate attack?

2.14.2:

Section needs more detail? What service is denied, and to whom?

Section 3:

The first paragraph says that it will be noted which mechanisms are  
required vs optional. Unless I missed something, the document does not  
do this in any formal way. I think this would be a good use of RFC  
2119 normative language.

Section 3.1 and 3.2

It seems to me that sections 3.1 and 3.2 belong in the main body of  
the document.

Section 5:

As far as I can tell, none of the references are actually referenced  
anywhere in the document.

_______________________________________________
Gen-art mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/gen-art

---

From: <[email-masked]>
Date: Tue, 22 Apr 2008 15:19:12 -0500

I have updated the draft to reflect your comments as
draft-ietf-rserpool-threats-10 and will be sending it to you tomorrow.
I have to put in the references and clean up a few other minor nits. 

Some of your comments need more response than just changing the
document.  I have below your comment for some of them followed by my
response.  I also changed text in the document in response to these.
For other comments that are not called out below, I simply changed the
document.

Section 2.3.3

This section needs more discussion. Is it possible for an authenticated
PE to send misinformation about another PE? Is this also an
authorization issue?

-------

Each PE sends information only about itself to the ENRP server.  As you
correctly point out, if PEs are allowed to speak for each other there is
a number of security issues that would be introduced.  The protocol
avoids this by requiring a PE to register only for itself.

Section 2.6.3

-------------------

A requirements document is just a discussion of security requirements
and does not contain advice to the implementor.  The advice to the
implementor is in the ASAP and ENRP documents in the security
considerations section.  The authentication method is TLS which is
described in ASAP and ENRP.  As I said in my first e-mail, I can copy
the text in ASAP and ENRP into the requirements document if you want.
Historical note: both IPsec and TLS fulfill the requirements in the
threat document.  After debating, we chose TLS.  

Section 2.8.3:

---------------------

Same answer as above.

Section 2.9.1:

I do not know the RSerPool details, but I would assume that if PE A
could take over for PE B for a given user, the user would have to have
the same trust relationship with PE B as for PE A. Is the point of this
section to say that RSerPool does not require this and should?

------------------------------

This trust between PU and PE is established at the application layer so
Rserpool doesn't have control over that.  Rserpool is a session layer
protocol.  Rserpool can notify the application when fail over occurs so
the application can take appropriate action.  That is the first option
called out in the requirements list.  We don't have a mechanism to
reestablish the security context transparently so I'll delete that
option.  It is not really an option since we don't know how to do it
:-).

Section 2.10.1:

--------------

Threee different threats that are all solved by an integrity mechanism.

2.14.1:

---------------

No, this is a separate attack.  See ENRP section 3.5.1.  It looks to me
like I have a cut/paste error and incorrectly stated the threat as
keep-alive between PU and ENRP server.  It should be keep-alive between
an ENRP server and PE which I fixed in the document.  An endpoint keep
alive message is sent from an ENRP server to a PE when the PE loses its
home ENRP server.  Sorry this was messed up but you caught it.  I think
I did a cut/paste from the previous section and didn't update it.

Section 3.1 and 3.2

It seems to me that sections 3.1 and 3.2 belong in the main body of the
document.

-------------------------

OK, I moved them to the main body of the document.

Thanks for your feedback.  It improved the document.

-- Maureen
Maureen Stillman
Nokia Services and Software
Mobile: (607)229-3358

-----Original Message-----
From: ext Ben Campbell [mailto:[email-masked]] 
Sent: Tuesday, April 08, 2008 5:32 PM
To: General Area Review Team
Cc: Sengodan Senthil (NSN - US/Irving); [email-masked];
[email-masked]; Gopal Ram (NSN - US/San Diego); Stillman Maureen
(Nokia-S&S/MtView); [email-masked]; [email-masked];
[email-masked]
Subject: Gen-ART Last Call review of draft-ietf-rserpool-threats-09

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

Comments:

--General:

It is not clear to me what this draft seeks to accomplish. Without being
an expert in RSerPool, it is not clear to me if the draft intends to
offer requirements for new security mechanisms into the RSerPool
protocol itself, or to offer guidance to implementors on how to securely
implement the protocol.

If the former, then it is vague in many places, but is probably on the
right track. However, would this mean that the other rserpool documents
currently in last call will need significant changes indicated by _this_
draft? That is, if this draft progresses then the other are by
definition not ready? (I fully admit not knowing the details of those
drafts.)

The document does not use normative language, nor does it reference RFC
2119. I know normative language is not always required for informational
RFCs, but it seems appropriate for this document, since it offers up
important security requirements.

--Specific Comments:

Section 1:

The purpose of the draft is not clear from the introduction (See general
comment above).

It would be nice to see a background paragraph describing what RSerPool
is. There is a quick mention in the abstract, but the document should be
"complete" without the abstract.

The introduction needs some references. (Actually, as far as I can tell
the entire document is devoid of references.)

Section 1.1:

Section 2.1.2:

The first sentence is a sentence fragment. This occurs in many of the
"Effect" sections--I am not going to repeat this comment each time, but
please proofread for this. The RFC Editor will probably fix it, but it's
always nice to save them work.

Section 2.2.2:

Section 2.3.2

Section 2.3.3

This section needs more discussion. Is it possible for an authenticated
PE to send misinformation about another PE? Is this also an
authorization issue?

Section 2.4.3:

Section 2.5.3

Section 2.6.3

Section 2.8.3:

Section 2.9.1:

I do not know the RSerPool details, but I would assume that if PE A
could take over for PE B for a given user, the user would have to have
the same trust relationship with PE B as for PE A. Is the point of this
section to say that RSerPool does not require this and should?

Section 2.9.2:

Section 2.9.3:

Are you saying that RSerPool fails to give tools so that a user can
establish the correct trust relationships with the new server when
failing over and needs them? Or do you mean to say that implementation
should use certain tools to do this? If the second, please call out the
mechanism.

Section 2.10.1:

2.10.2:

2.10.3:

2.12.-1 and 2.12.2:

The organization of these sections is confusing, and not consistent with
that of the earlier sections. It is not clear to me how the effects line
up with the threats. That is, is effect a. related to threat a., or is
it related to all listed threats?

2.12.1 a.

2.12.1 c.

2.12.3:

None of the attacks described in 2.12.* seem to be about confidentiality
per se.

2.13.1:

2.13.2:

2.14.1:

2.14.2:

Section 3:

Section 3.1 and 3.2

It seems to me that sections 3.1 and 3.2 belong in the main body of the
document.

Section 5:

---

From: Ben Campbell <[email-masked]>
Date: Mon, 28 Apr 2008 16:33:54 -0500

Thanks for the response!

This email is just in response to your emailed comments--I will  
respond to the update document separately.

On Apr 22, 2008, at 3:19 PM, <[email-masked]> <[email-masked] 
 > wrote:

> authenticated

Thanks! It would be helpful to mention that in the document.

> say that the RSerPool protocol does not provide such a mechanism and

I don't know that its necessary to copy whole sections from the ASAP  
and ENRP documents, but it would be helpful if this document very  
briefly mentioned what mechanisms the protocols use for each  
requirement.

> Same question about mechanism as in my previous comment.

And same response :-)

> this

Is there some guidance in one of the other documents on what the  
application should do when it receives such a notification?

> Is this one threat, or three different threats?

I still find the structure confusing. It might be helpful to put a  
paragraph (prior to the labeled sub-items) that mentions that these  
threats are all just examples of data-corruption or tampering threats.

> Also, Is this not really the a consequence of 2.13, rather than a

OK

> the

OK

> Thanks for your feedback.  It improved the document.

Thanks!

[...]

---

From: <[email-masked]>
Date: Tue, 29 Apr 2008 09:24:55 -0500

One additional comment:  The sec-dir reviewer said that he thought a
provision for authentication MUST be present and a provision for data
confidentiality service SHOULD be present.
I went with his recommendation on the MUST, SHOULD text.

Hope that is OK with you. 

-- Maureen
Maureen Stillman

-----Original Message-----
From: ext Ben Campbell [mailto:[email-masked]] 
Sent: Monday, April 28, 2008 5:34 PM
To: Stillman Maureen (Nokia-S&S/MtView)
Cc: [email-masked]; Sengodan Senthil (NSN - US/Irving);
[email-masked]; [email-masked]; Gopal Ram (NSN - US/San
Diego); [email-masked]; [email-masked]
Subject: Re: Gen-ART Last Call review of draft-ietf-rserpool-threats-09

Thanks for the response!

This email is just in response to your emailed comments--I will respond
to the update document separately.

> an authorization issue?
>
> -------
>
> Each PE sends information only about itself to the ENRP server.  As 
> you correctly point out, if PEs are allowed to speak for each other 
> there is a number of security issues that would be introduced.  The 
> protocol avoids this by requiring a PE to register only for itself.

> say that the RSerPool protocol does not provide such a mechanism and 

I don't know that its necessary to copy whole sections from the ASAP and
ENRP documents, but it would be helpful if this document very briefly
mentioned what mechanisms the protocols use for each requirement.

And same response :-)

> This trust between PU and PE is established at the application layer 
> so Rserpool doesn't have control over that.  Rserpool is a session 
> layer protocol.  Rserpool can notify the application when fail over 
> occurs so the application can take appropriate action.  That is the 
> first option called out in the requirements list.  We don't have a 
> mechanism to reestablish the security context transparently so I'll 
> delete that option.  It is not really an option since we don't know 
> how to do it :-).

> No, this is a separate attack.  See ENRP section 3.5.1.  It looks to 
> me like I have a cut/paste error and incorrectly stated the threat as 
> keep-alive between PU and ENRP server.  It should be keep-alive 
> between an ENRP server and PE which I fixed in the document.  An 
> endpoint keep alive message is sent from an ENRP server to a PE when 
> the PE loses its home ENRP server.  Sorry this was messed up but you 
> caught it.  I think I did a cut/paste from the previous section and 
> didn't update it.

OK

OK

Thanks!

[...]

---

From: Ben Campbell <[email-masked]>
Date: Tue, 29 Apr 2008 10:54:32 -0500

On Apr 29, 2008, at 9:24 AM, <[email-masked]> <[email-masked] 

> Hope that is OK with you.

Yes, that works for me.

Thanks!