Re: [secdir] Urgent need for a person from the security directorate to review key pionts in I2RS security

[Kathleen Moriarty <[e-mail]>]

Hi,

Can we have a volunteer to assist with this request for an early review on I2RS work?

Tero is on vacation and I'm not sure who would be next in the rotation, but it would also be good to have someone interested in the topic.

Thank you!
Kathleen 

Sent from my iPhone

> On Aug 14, 2015, at 12:47 PM, Susan Hares <[e-mail]> wrote:
> 
> Security directorate:
>  
> I need help rather urgently.  The I2RS and the NETCONF WGs are collaborating to create the I2RS protocol.  The design team will begin its work next week (8/17) so I need someone who can help for the next 2 weeks.  We really need a security person to help us for the next few weeks to determine what are necessary security requirements for this protocol.   I am willing to provide tutorial and information for the security person.
>  
> NETCONF reviewers have suggested that some of the I2RS security requirements are unclear or “not security” requirements.  The NETCONF reviewers have also suggested that the optional insecure transport for non-configuration data) will not be approved by the security ADs or reviewers.  Rather that both groups arguing over what they think a security reviewer will say – we’d like a person from the security directorate to speak for the security area. 
>  
> The security directorate has really help us in forming our work.  We had a great security review on the I2RS architecture in December 2014/January 2015 from Tero Kivinen ([e-mail]) Also our GEN-ART review from Russ Housley also suggested issues.  After these issues we split our security work into wire-protocol security and environment security.  We need help to determine that we have split the work correctly.  We are heading into WG adoption call on these drafts next week.
>  
> The details are in the message below I sent to Kathleen and Stephen.  However, I recalled that last time I also need to send email to saag group that helped me get a reviewer.
>  
> Sue Hares
> I2RS co-chair.
>  
> From: Susan Hares [mailto:[e-mail]] 
> Sent: Friday, August 14, 2015 11:59 AM
> To: 'Kathleen Moriarty'; 'Stephen Farrell'
> Cc: 'Alia Atlas'
> Subject: Urgent need for a person from the security directorate to review key pionts in I2RS security
>  
> Kathleen and Stephen:
>  
> I sent you a request at IETF that we need a security person from the security directorate to review the following I2RS security drafts.
>  
> http://datatracker.ietf.org/doc/draft-hares-i2rs-auth-trans/
> http://datatracker.ietf.org/doc/draft-mglt-i2rs-security-requirements/
> and a revision of
> http://datatracker.ietf.org/doc/draft-mglt-i2rs-security-requirements/
>  
> Perhaps you will recall I mentioned this to you on Friday of IETF.  My need has turned from urgent (in July) to “very urgent” as we start I2RS-netconf design team to work on the  I2RS protocol design next week.   Would you please find some who can advise me from the security directorate?  The details are below.
>  
> Sue Hares
> ------------------
>  
> Document 1)  http://datatracker.ietf.org/doc/draft-hares-i2rs-auth-trans/
>  
> We had editorial feedback on requirements 3 and 4 that these requirement need clarification, and requirement 10 is ambiguous.  We would like feedback on what the security person on this need for editorial review, and
> review of the alternate text.
>  
> In this document, we have feedback from Netconf that Requirement 8 and 12 are not security requirements.
>  
> ·         SEC-REQ-08: Each Identity is associated with one secondary
> identity during a particular read/write sequence, but the
>     secondary identity may vary during the time a connection between
>     the I2RS client and I2RS agent is active.  The variance of the
>     secondary identity allows the I2rs client to be associated with
>     multiple applications and pass along an identifier for these
>     applications in the secondary identifier.
>  
> ·         SEC-REQ-12: The I2RS Client and I2RS Agent protocol SHOULD implement
>    mechanisms that mitigate DoS attacks
>  
> Our input from the Ericsson network security is the mitigation of DDos was important.
>  
> Also, the I2RS protocol will have a multiple message sequence in which the local system can:
>    1.  Perform all or none: All operations succeed or none of them will
>        be applied.  This useful when there are mutual dependencies.
>  
>    2.  Perform until error: Operations are applied in order, and when
>        error occurs the processing stops.  This is useful when
>        dependencies exist between multiple-message operations, and order
>        is important.
>  
>    3.  Perform all storing errors: Perform all actions storing error
>        indications for errors.  This method can be used when there are
>        no dependencies between operations, and the client wants to sort
>        it out.
>  
> Is the ability to do impact security?  If so, we need to craft this work.
> If not, we will pull this from the security section.
>  
> Lastly, the I2RS group early in its architecture decided that it was important to provide some information via an insecure connection.  Publishing information via an insecure connection must consider the information and the context.  This insecure data was going to be used to provide global information that ISPs would want to publish to public from a router.
>  
> The architecture document:
> http://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/
>  
> I will be calling for the I2RS WG to reconsider the insecure connection, but I suspect the I2RS WG will want the secure connection.   I need a person from the security directorate to discuss the issues with during the WG call regarding the insecure connection.   Unless there is overwhelming agreement to get rid of the insecure connection, the I2RS chairs and AD are likely to keep it in.
>  
> Document 2) http://datatracker.ietf.org/doc/draft-mglt-i2rs-security-requirements/
>  
> This draft considers the security environment that the I2RS operates within.  The security review in December 2014 indicated several comments that led us to work on a security environment draft.
>  
>  
>  
>  
>  
>