Subject: [manet] Adrian Farrel's Yes on draft-ietf-manet-ibs-03: (with COMMENT)

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 22 Nov 2014 06:43:40 -0800

Adrian Farrel has entered the following ballot position for
draft-ietf-manet-ibs-03: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-manet-ibs/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I have cleared my Discuss. I am satisfied that the author has engaged
properly in discussion with the SecDir reviewer and that the document
itself is sound.

The only addition I can see arising from this debate is some text to
further explain the trust model in using IBS: it may not be suitable for
everyone, but it's offered as an option for those for whom it is
suitable.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 24 Nov 2014 09:26:02 +0000

There is already some text to this effect, from the Introduction

   The disadvantage referred to is that the trusted authority has
   complete authority, even more so than a conventional certificate
   authority.  Routers cannot generate their own private keys, only the
   trusted authority can do that.  Through the master secret held by the
   trusted authority, it could impersonate any router (existing or not).
   When used for identity-based encryption (not part of this
   specification) the trusted authority can decrypt anything.  However,
   note that the shared secret key options described in [RFC7182] also
   have this limitation.

And from the Security Considerations

   In common with other forms of IBS, a feature of the form of IBS
   (known as ECCSI) used in this specification is that it requires a
   trusted authority (KMS) that issues all private keys, and has
   complete cryptographic information about all possible private keys.
   However to set against that, the solution is scalable, as all routers
   can be independently keyed, and does not need the KMS in the network.
   If no future keys will be required, then the KMS's master secret can
   be destroyed.  As routers are individually keyed, key revocation (by
   blacklist and time expiry of keys) is possible, but is beyond the
   scope of this specification.

However it doesn't explicitly call out that this is an option for those who are prepared to accept this limitation. (I guess I was assuming that was implied by the above and that RFC 7182 is, of its nature, a set of options.)

I will see what else is produced as comments before creating an updated draft.

-- 
Christopher Dearlove
Senior Principal Engineer, Information Assurance Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
[email-masked] | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: manet [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: 22 November 2014 14:44
To: The IESG
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: [manet] Adrian Farrel's Yes on draft-ietf-manet-ibs-03: (with COMMENT)

----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages.
--------------------------------------------------------

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

I have cleared my Discuss. I am satisfied that the author has engaged properly in discussion with the SecDir reviewer and that the document itself is sound.

The only addition I can see arising from this debate is some text to further explain the trust model in using IBS: it may not be suitable for everyone, but it's offered as an option for those for whom it is suitable.

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

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************