Subject: [manet] Stephen Farrell's Discuss on draft-ietf-manet-ibs-03: (with DISCUSS)

From: "Stephen Farrell" <[email-masked]>
Date: Mon, 24 Nov 2014 03:47:41 -0800

Stephen Farrell has entered the following ballot position for
draft-ietf-manet-ibs-03: Discuss

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/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

(1) I am concerned that RFC6507 may not be ready for use in
standards-track RFCs. So far it has not been and I have found
no peer reviewed security or cryptographic analysis that
indicates that it is has been studied to see if it is good
enough for that. I've also not seen any MANET list discussion
of that aspect (and indeed the MANET list discussion I did
see seems to involve very few people).  I asked on the CFRG
list about RFC6507 and it seems [1] to be the case that
no-one has so far really evaluated its security, other than
folks associated with the author's institution. (Which
applies to both 6507 and this I think.) I also didn't find
any references to 6507 in Google scholar.  Lastly, I think we
should be, and be seen to be, more careful than usual with
this draft - given the situation with DUAL-EC-DRBG, and that
this is a new signature scheme that allows the KMS to fake
anyone's signature and the author involved.  Note that that
last is not any imputation of misbehaviour, but the IETF
would not be  doing due-dilligence if we didn't explicitly
consider that aspect.

  [1] https://www.ietf.org/mail-archive/web/cfrg/current/msg05540.html

(2) How does a router get its private key? Why is it ok to
not specify that? Seems like an interop fail if that is not
done.

(3) I think this is the first asymmetric scheme the WG have
adopted. If that's wrong then this discuss point is fairly
moot:-) When did the WG discuss whether to adopt IBS as its
first asymmetric appraoch and not traditional signature
schemes that don't have spoofing by the KG/KMS as an inherent
property? That might be a reasonable decision, but I don't
see where that decision was made, nor why. (That could be
just that I've not looked far enough back in the WG list
archives, in which case this is easy.)

(4) 4.1: The usual revocation trick of including a time value
in the name is referred to at the end of this section but
without sufficient detail to allow interop. Why is that ok?

(5) RFC6507 isn't compatible with e.g. Curve25519 or perhaps
other "rigid" curves. Given that CFRG are in the process of
picking new curves, with better properties, wouldn't it be
better for the WG to wait and have the choice of using those
as well or instead?

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 24 Nov 2014 12:06:51 -0000

Thanks Stephen,

Some good and bad questions here, I think.

Wrt 1, is IBS sufficiently bad and unknown that using it is worse than having no security?

Wrt 2, I suspect that the key distribution being contemplated is physical, but we can certainly talk about it.

Wrt 5, do you think that waiting for the output of a research group is right? Firstly, this doesn't bring us anything closer to something we can include in a standards track RFC, and secondly it doesn't give us any security we can implement today.

A

> -----Original Message-----
> From: iesg [mailto:[email-masked]] On Behalf Of Stephen Farrell
> Sent: 24 November 2014 11:48
> To: The IESG
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Stephen Farrell's Discuss on draft-ietf-manet-ibs-03: (with DISCUSS)
>

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 24 Nov 2014 12:20:28 +0000

> Wrt 1, is IBS sufficiently bad and unknown that using it is worse

Given that there are far better known asymmetric schemes my
question#1 is valid I think. This draft seems to be picking
the cryptographically unknown over the known and is the first
standards-track document to do so.

> Wrt 2, I suspect that the key distribution being contemplated is
> physical, but we can certainly talk about it.

Right. I don't know how to get interop between router and KMS
without at least e.g. defining a format or some kind of interface.

> Wrt 5, do you think that waiting for the output of a research group
> is right? Firstly, this doesn't bring us anything closer to something
> we can include in a standards track RFC, and secondly it doesn't give
> us any security we can implement today.

Not waiting is quite arguable yes. However, the TLS wg are waiting
for this, albeit without that currently blocking progress, so it'll
be relatively quick (as in weeks, is the plan). I wasn't clear if
the MANET WG were aware of that, since CFRG have only been working
on that since earlier this year. The new curves are being picked
because they have both CPU and side-channel resistance advantages
that could be relevant here and I saw no sign that the work had
been factored into this at all. (It may well have of course, as I
said, I only went back a little into the MANET list archive.)

S.

> 
> A
> 
>> -----Original Message----- From: iesg
>> [mailto:[email-masked]] On Behalf Of Stephen Farrell Sent:
>> 24 November 2014 11:48 To: The IESG Cc:
>> [email-masked];
>> [email-masked]; [email-masked];
>> [email-masked] Subject: Stephen Farrell's Discuss on
>> draft-ietf-manet-ibs-03: (with DISCUSS)
>> 
>> 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/
>> 
>> 
>> 
>> standards-track RFCs. So far it has not been and I have found no
>> peer reviewed security or cryptographic analysis that indicates
>> that it is has been studied to see if it is good enough for that.
>> I've also not seen any MANET list discussion of that aspect (and
>> indeed the MANET list discussion I did see seems to involve very
>> few people).  I asked on the CFRG list about RFC6507 and it seems
>> [1] to be the case that no-one has so far really evaluated its
>> security, other than folks associated with the author's
>> institution. (Which applies to both 6507 and this I think.) I also
>> didn't find any references to 6507 in Google scholar.  Lastly, I
>> think we should be, and be seen to be, more careful than usual
>> with this draft - given the situation with DUAL-EC-DRBG, and that 
>> this is a new signature scheme that allows the KMS to fake anyone's
>> signature and the author involved.  Note that that last is not any
>> imputation of misbehaviour, but the IETF would not be  doing
>> due-dilligence if we didn't explicitly consider that aspect.
>> 
>> [1]
>> https://www.ietf.org/mail-archive/web/cfrg/current/msg05540.html
>> 
>> (2) How does a router get its private key? Why is it ok to not
>> specify that? Seems like an interop fail if that is not done.
>> 
>> adopted. If that's wrong then this discuss point is fairly moot:-)
>> When did the WG discuss whether to adopt IBS as its first
>> asymmetric appraoch and not traditional signature schemes that
>> don't have spoofing by the KG/KMS as an inherent property? That
>> might be a reasonable decision, but I don't see where that decision
>> was made, nor why. (That could be just that I've not looked far
>> enough back in the WG list archives, in which case this is easy.)
>> 
>> (4) 4.1: The usual revocation trick of including a time value in
>> the name is referred to at the end of this section but without
>> sufficient detail to allow interop. Why is that ok?
>> 
>> (5) RFC6507 isn't compatible with e.g. Curve25519 or perhaps other
>> "rigid" curves. Given that CFRG are in the process of picking new
>> curves, with better properties, wouldn't it be better for the WG to
>> wait and have the choice of using those as well or instead?
>> 
>> 
> 
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 24 Nov 2014 13:58:03 +0000

Thanks Adrian and Stephen.

With regard to point 1, I am attempting to obtain some additional material. In the meantime, you may want to note http://www.cesg.gov.uk/policyguidance/Documents/white_paper-using_MIKEY-SAKKE.pdf though I am not claiming it addresses your complete point. It is also possible to identify that CESG are working with various other parties on MIKEY-SAKKE (we are just using ECCSI from that of course), my Googling identifies Cellcrypt (who I am not familiar with) as one such. That note does however indicated that ECCSI is, fundamentally, a modification of ECDSA. However I am not a cryptographer to make a detailed comment there. With regard to the trusted authority issue, as has been said, this is an option. It's actually a safer option than the shared secret key options that make up most of RFC 7182's existing options.

With regard to 2, this is exactly the same as any other RFC 7182 algorithm. We went through a long discussion as to this for that protocol, all the same arguments apply unchanged.

With regard to 3, actually RFC 7182 lists RSA as an already supported algorithm. That dates back to its predecessor RFC 6622 (which I wasn't an author of, so don't recall any discussion there).

With regard to 4, primarily I would regard specifying this as a possible future extension (which could be done now in an administratively configured manner) because different uses of this might have different requirements (granularity, duration). An option could be selected, but since this would be in support of an also administratively configured policy, this seemed not worthwhile.

I do not believe that point 5 is appropriate. The CFRG is aimed at a different issue, support of TLS, with different requirements, and not for an identity based scheme.

With regard to the related CFRG point in comment 1, I followed that discussion, it was very short, hardly anyone contributed, and the only conclusion I'd draw from it is that a couple of people expressed they didn't know, that was it. (There were also IPR points made, but see the CESG document linked above.)

Christopher

-- 
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: Adrian Farrel [mailto:[email-masked]] 
Sent: 24 November 2014 12:07
To: 'Stephen Farrell'; 'The IESG'
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: Stephen Farrell's Discuss on draft-ietf-manet-ibs-03: (with DISCUSS)

----------------------! 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.
--------------------------------------------------------

Thanks Stephen,

A

> 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
> standards-track RFCs. So far it has not been and I have found no peer 
> reviewed security or cryptographic analysis that indicates that it is 
> has been studied to see if it is good enough for that. I've also not 
> seen any MANET list discussion of that aspect (and indeed the MANET 
> list discussion I did see seems to involve very few people).  I asked 
> on the CFRG list about RFC6507 and it seems [1] to be the case that 
> no-one has so far really evaluated its security, other than folks 
> associated with the author's institution. (Which applies to both 6507 
> and this I think.) I also didn't find any references to 6507 in Google 
> scholar.  Lastly, I think we should be, and be seen to be, more 
> careful than usual with this draft - given the situation with 
> DUAL-EC-DRBG, and that this is a new signature scheme that allows the 
> KMS to fake anyone's signature and the author involved.  Note that 
> that last is not any imputation of misbehaviour, but the IETF would 
> not be  doing due-dilligence if we didn't explicitly consider that 
> aspect.
> 
> (2) How does a router get its private key? Why is it ok to not specify 
> that? Seems like an interop fail if that is not done.
> 
> (3) I think this is the first asymmetric scheme the WG have adopted. 
> If that's wrong then this discuss point is fairly
> moot:-) When did the WG discuss whether to adopt IBS as its first 
> asymmetric appraoch and not traditional signature schemes that don't 
> have spoofing by the KG/KMS as an inherent property? That might be a 
> reasonable decision, but I don't see where that decision was made, nor 
> why. (That could be just that I've not looked far enough back in the 
> WG list archives, in which case this is easy.)
> 
> (4) 4.1: The usual revocation trick of including a time value in the 
> name is referred to at the end of this section but without sufficient 
> detail to allow interop. Why is that ok?
> 

********************************************************************
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.
********************************************************************

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 24 Nov 2014 15:53:13 +0000

I just want to pick up on " far better known asymmetric schemes". Better known, yes. Better? Or even equally good for some requirements (those this is for)?  Note that there are important different properties of IBS (whether ECCSI, or other IBS schemes) that aren't shared by other asymmetric schemes I'm aware of.

Specifically, with this, or other, IBS schemes you can do the following:

Router A receives private key from KMS. In the systems of interest to us, this would be in a secure location, but that's not the only possibility. Router A is not given any information about B.C,D, ..., indeed some of those might not even exist at this point.

Routers A,B,C,D, ... are sent into the field. The KMS is not. When router A receives a message (or packet, as appropriate) from router B it needs nothing specific from B except its identity. (And that's zero overhead when the identity is an IP address.) In particular no certificates.

Note that who could claim precedence for first suggesting IBE/IBS (not specifically ECCSI, that's a realisation of the concept) for ad hoc networks could be debated. But I'm aware of published work dating back at least as far as 2005.

-----Original Message-----
From: manet [mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: 24 November 2014 12:20
To: [email-masked]; 'The IESG'
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [manet] Stephen Farrell's Discuss on draft-ietf-manet-ibs-03: (with DISCUSS)

S.

>> wait and have the choice of using those as well or instead?

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

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 24 Nov 2014 16:08:00 +0000

Hiya,

On 24/11/14 15:53, Dearlove, Christopher (UK) wrote:
> I just want to pick up on " far better known asymmetric schemes".
> Better known, yes. 

That is my main point. Well-known and well-studied are important
properties for standards-track crypto mechanisms, I'm sure you'll
agree. That ECCSI is nowhere near as well-studied as say ECDSA or
RSA is a real issue. For example, its not unlikely that once one
standards-track RFC uses it, others will follow, so we need to
take care with this stuff.

> Better? Or even equally good for some requirements
> (those this is for)?  Note that there are important different
> properties of IBS (whether ECCSI, or other IBS schemes) that aren't
> shared by other asymmetric schemes I'm aware of.
> 
> Router A receives private key from KMS. In the systems of interest to
> us, this would be in a secure location, but that's not the only
> possibility. Router A is not given any information about B.C,D, ...,
> indeed some of those might not even exist at this point.

Well, all routers need the same domain parameters but sure.

> Routers A,B,C,D, ... are sent into the field. The KMS is not. When
> router A receives a message (or packet, as appropriate) from router B
> it needs nothing specific from B except its identity. (And that's
> zero overhead when the identity is an IP address.) In particular no
> certificates.

No certificates is grand, and as per above the verifier needs to know
the same domain parameters and not only the IP address, but certs are
not at issue in the discuss.

> Note that who could claim precedence for first suggesting IBE/IBS
> (not specifically ECCSI, that's a realisation of the concept) for ad
> hoc networks could be debated. But I'm aware of published work dating
> back at least as far as 2005.

Yes, but not afaik based on this particular scheme.

S.

---

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

Agreed, ECCSI for ad hoc networks does not date back to 2005. But observation of the desirability of the characteristics of IBS (including ECCSI) in some ad hoc networks dates back at least that far.

Well known is good. But what is well known and has the required properties?

I'm not aware of an IBS method that would have less resistance than ECCSI (I am aware of at least two other IBS methods). We do at least have an RFC for ECCSI. (Also the others I'm aware of are harder and slower to implement, though they can produce smaller signatures.)

As I said, I'm hoping to get some more input on the subject. Not that, but you might also speak to Kenny Paterson (CFRG co-chair) on the subject. I do not know his views on ECCSI specifically (so I'm offering a hostage to fortune) and he might decline to comment. But he has the expertise.

(Yes, all routers  need same domain parameters, which can be passed at same time as private key. The point is that they aren't router specific. Parenthesised comment as I don't think this is a point at issue.)

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: 24 November 2014 16:08
To: Dearlove, Christopher (UK); [email-masked]; 'The IESG'
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [manet] Stephen Farrell's Discuss on draft-ietf-manet-ibs-03: (with DISCUSS)

Hiya,

> I just want to pick up on " far better known asymmetric schemes".

That is my main point. Well-known and well-studied are important properties for standards-track crypto mechanisms, I'm sure you'll agree. That ECCSI is nowhere near as well-studied as say ECDSA or RSA is a real issue. For example, its not unlikely that once one standards-track RFC uses it, others will follow, so we need to take care with this stuff.

> Better? Or even equally good for some requirements (those this is 
> for)?  Note that there are important different properties of IBS 
> (whether ECCSI, or other IBS schemes) that aren't shared by other 
> asymmetric schemes I'm aware of.
> 

> it needs nothing specific from B except its identity. (And that's zero 
> overhead when the identity is an IP address.) In particular no 
> certificates.

No certificates is grand, and as per above the verifier needs to know the same domain parameters and not only the IP address, but certs are not at issue in the discuss.

> Note that who could claim precedence for first suggesting IBE/IBS (not 
> specifically ECCSI, that's a realisation of the concept) for ad hoc 
> networks could be debated. But I'm aware of published work dating back 
> at least as far as 2005.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 24 Nov 2014 16:25:51 +0000

Hiya,

On 24/11/14 16:21, Dearlove, Christopher (UK) wrote:
> Agreed, ECCSI for ad hoc networks does not date back to 2005. But
> observation of the desirability of the characteristics of IBS
> (including ECCSI) in some ad hoc networks dates back at least that
> far.
> 

So perhaps that suggests addressing that part of the discuss
first then. (part 3) Why do the WG (not your specific deployments)
need IBS? When was that discussed?

S.

> 
> I'm not aware of an IBS method that would have less resistance than
> ECCSI (I am aware of at least two other IBS methods). We do at least
> have an RFC for ECCSI. (Also the others I'm aware of are harder and
> slower to implement, though they can produce smaller signatures.)
> 
> As I said, I'm hoping to get some more input on the subject. Not
> that, but you might also speak to Kenny Paterson (CFRG co-chair) on
> the subject. I do not know his views on ECCSI specifically (so I'm
> offering a hostage to fortune) and he might decline to comment. But
> he has the expertise.
> 
> (Yes, all routers  need same domain parameters, which can be passed
> at same time as private key. The point is that they aren't router
> specific. Parenthesised comment as I don't think this is a point at
> issue.)
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 24 Nov 2014 16:32:31 +0000

Essentially I would say that the knowledge that IBS is a good fit to some ad hoc networks is well-known to many in that community. I made a proposal to standardise a version thereof to extend the range of options in RFC 7182, which already has the main competitors (several shared key variants, RSA) in it. We had no one saying it was a bad idea, and some people saying it's what they wanted. Some people in the latter camp probably aren't minded to discuss their specifics if they don't need to, for reasons look at the affiliations of several people in the group. As such, I think the requirement to have an IBS scheme (I'm not addressing the choice of IBS scheme here) as an option wasn't really very contentious, because no one contended.

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: 24 November 2014 16:26
To: Dearlove, Christopher (UK); [email-masked]; 'The IESG'
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [manet] Stephen Farrell's Discuss on draft-ietf-manet-ibs-03: (with DISCUSS)

Hiya,

> Well known is good. But what is well known and has the required 

So perhaps that suggests addressing that part of the discuss first then. (part 3) Why do the WG (not your specific deployments) need IBS? When was that discussed?

S.

> As I said, I'm hoping to get some more input on the subject. Not that, 
> but you might also speak to Kenny Paterson (CFRG co-chair) on the 
> subject. I do not know his views on ECCSI specifically (so I'm 
> offering a hostage to fortune) and he might decline to comment. But he 
> has the expertise.
> 
> (Yes, all routers  need same domain parameters, which can be passed at 
> same time as private key. The point is that they aren't router

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 26 Nov 2014 17:37:45 -0800

Agree, that is important in the dynamic MANET, however, in MANET our
routers are able to be moving very fast so joining groups and leaving
in essential. The problem with our MANETs in this group is the
management, our draft regarding management is still slow in its
process. I rememebr asking Robert the author of the management draft
but still did not get a respond. The protocol management issue was
discussed in this WG, but was not taked forward (or even followed up)
by the WG managers. I suggest that IETF WGs managers/Chairs look into
open issues-discussed and link them into our drafts. We repeat our
questions many times in our WGs and sometimes we will get IESG mention
what we discussed but we still did not solve.

I suggest we start to solve this protocol management issue in this
draft, so we need to discuss how each router can get the key or even
when the key can be changed. Our we make up the conditions that makes
a router get the key and when it can change it to another.

AB

---

From: Jiazi YI <[email-masked]>
Date: Thu, 27 Nov 2014 14:54:24 +0100

I think the key distribution is an important (and hard, especially if there
is no centralised CA) issue for MANET.
I believe it's better to have it discussed in a separate document, rather
than in this draft.
Solving the management issue is even out of the scope.

best

Jiazi

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 27 Nov 2014 15:24:35 +0000

In particular, all the arguments that kept key management out of RFC 7182 apply equally well here.

[email-masked]<mailto:[email-masked]> | http://www.baesystems.com

From: manet [mailto:[email-masked]] On Behalf Of Jiazi YI
Sent: 27 November 2014 13:54
To: Abdussalam Baryun
Cc: Thomas Clausen; manet; [email-masked]; The IESG; <[email-masked]>; Stephen Farrell
Subject: Re: [manet] Stephen Farrell's Discuss on draft-ietf-manet-ibs-03: (with DISCUSS)

*** WARNING ***
This message originates from outside our organisation, either from an external partner or the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
For information regarding Red Flags that you can look out for in emails you receive, click here<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.
If you feel the email is suspicious, please follow this process<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.
I think the key distribution is an important (and hard, especially if there is no centralised CA) issue for MANET.
I believe it's better to have it discussed in a separate document, rather than in this draft.
Solving the management issue is even out of the scope.

best

Jiazi

On Thu, Nov 27, 2014 at 2:37 AM, Abdussalam Baryun <[email-masked]<mailto:[email-masked]>> wrote:

AB

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

---

From: Henning Rogge <[email-masked]>
Date: Thu, 27 Nov 2014 16:27:36 +0100

And lets not forget the type of key-management you need is highly
dependent on the organization of your deployment, independently from
the security mechanism (shared key/ibs) you use.

If you just produce a bunch of nodes together and use them without
touching them again, setting up static keys might be fine.

If you want to add/remove nodes later, you will most likely need some
complicated certificate based system.

Deploy a community mesh without a central authority? Maybe you will
need some "web of trust" style key management.

Henning Rogge

On Thu, Nov 27, 2014 at 4:24 PM, Dearlove, Christopher (UK)
<[email-masked]> wrote:
> Cc: Thomas Clausen; manet; [email-masked]; The
> IESG; <[email-masked]>; Stephen Farrell
> For information regarding Red Flags that you can look out for in emails you
> receive, click here.
> If you feel the email is suspicious, please follow this process.
>
> On Thu, Nov 27, 2014 at 2:37 AM, Abdussalam Baryun
> <[email-masked]> wrote:
>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 27 Nov 2014 15:46:11 +0000

Actually that discuss point is about interop and not about
security as in BCP107. If an IBS scheme is to be used then
there is a need for different node/router vendors to work
with the same KG/KMS and that needs to be specified for
each IBS scheme and is missing here. Perhaps it is in some
other or planned document? Absent that this scheme can
only be used for homogeneous manets where the same vendor
produces all the routers/nodes and the KG/KMS.

For other cryptographic schemes, e.g. those using shared
secrets or certs, we do have a number of ways of handling
this, but IBS schemes are new and are handling new kinds
of structed data (the private key and KG parameters)
therefore ISTM he lack of that bit of specification will
prevent interop.

S.

On 27/11/14 15:24, Dearlove, Christopher (UK) wrote:
> -- 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 
> 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
> 
> Sent: 27 November 2014 13:54 To: Abdussalam Baryun Cc: Thomas
> Clausen; manet; [email-masked]; The IESG;
> <[email-masked]>; Stephen Farrell Subject: Re: [manet]
> Stephen Farrell's Discuss on draft-ietf-manet-ibs-03: (with DISCUSS)
> 
> 
> *** WARNING *** This message originates from outside our
> organisation, either from an external partner or the internet. 
> Consider carefully whether you should click on any links, open any
> attachments or reply. For information regarding Red Flags that you
> can look out for in emails you receive, click
> here<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.
>
> 
If you feel the email is suspicious, please follow this
process<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.
> I think the key distribution is an important (and hard, especially if
> there is no centralised CA) issue for MANET. I believe it's better to
> have it discussed in a separate document, rather than in this draft. 
> <[email-masked]<mailto:[email-masked]>>
> wrote: On 11/24/14, Stephen Farrell
> <[email-masked]<mailto:[email-masked]>> wrote:
>> not specify that? Seems like an interop fail if that is not done.
>> 
> 
> routers are able to be moving very fast so joining groups and
> leaving in essential. The problem with our MANETs in this group is
> the management, our draft regarding management is still slow in its 
> discussed in this WG, but was not taked forward (or even followed
> up) by the WG managers. I suggest that IETF WGs managers/Chairs look
> into open issues-discussed and link them into our drafts. We repeat
> our questions many times in our WGs and sometimes we will get IESG
> mention what we discussed but we still did not solve.
> 
> when the key can be changed. Our we make up the conditions that
> makes a router get the key and when it can change it to another.
> 
> AB
> 
> _______________________________________________ manet mailing list

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 27 Nov 2014 15:53:24 +0000

Again, I see no difference here from the rest of RFC 7182. Arguments which the IESG including Stephen accepted.

I am aware of a MIKEY-SAKKE based certificate format that includes an ECCSI key (and other material), but I don't know if published or not.

But since this the least of Stephen's objections, I'm not going to spend cycles on this one at this time.

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: 27 November 2014 15:46
To: Dearlove, Christopher (UK); Jiazi YI; Abdussalam Baryun
Cc: Thomas Clausen; manet; [email-masked]; The IESG; <[email-masked]>
Subject: Re: [manet] Stephen Farrell's Discuss on draft-ietf-manet-ibs-03: (with DISCUSS)

Actually that discuss point is about interop and not about security as in BCP107. If an IBS scheme is to be used then there is a need for different node/router vendors to work with the same KG/KMS and that needs to be specified for each IBS scheme and is missing here. Perhaps it is in some other or planned document? Absent that this scheme can only be used for homogeneous manets where the same vendor produces all the routers/nodes and the KG/KMS.

For other cryptographic schemes, e.g. those using shared secrets or certs, we do have a number of ways of handling this, but IBS schemes are new and are handling new kinds of structed data (the private key and KG parameters) therefore ISTM he lack of that bit of specification will prevent interop.

S.

On 27/11/14 15:24, Dearlove, Christopher (UK) wrote:
> 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
> Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK 
> Sent: 27 November 2014 13:54 To: Abdussalam Baryun Cc: Thomas Clausen; 
> manet; [email-masked]; The IESG; 
> *** WARNING *** This message originates from outside our organisation, 
> either from an external partner or the internet.
> attachments or reply. For information regarding Red Flags that you can 
> look out for in emails you receive, click

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 27 Nov 2014 15:55:04 +0000

On 27/11/14 15:53, Dearlove, Christopher (UK) wrote:
> Again, I see no difference here from the rest of RFC 7182. Arguments
> which the IESG including Stephen accepted.
> 
> I am aware of a MIKEY-SAKKE based certificate format that includes an
> ECCSI key (and other material), but I don't know if published or
> not.
> 

Fair enough. I do however see a difference vs. 7182 but maybe
I'm not explaining it well. We can get to it when you're ready.

S.

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 28 Nov 2014 19:36:33 -0800

> Solving the management issue is even out of the scope.

I think the/any adopted-draft should discuss what is related to
draft/protocol purpose and use. In MANET use it is important to answer
the questions related to the mobile/node self-organisation, which is
important in this related to this protocol. What is out or in scope
should be decided within a use case, so what use case did you think of
for this protocol to have no management while using keys?

Best,

AB