IBAKE: Identity-Based Authenticated Key Exchange
draft-cakulev-ibake-06

[Ballot comment]
I think this document is in disagreement with what was said earlier on RFC 6267. Specifically, some of text that we added to balance the benefits and characteristics of IBAKE in RFC 6267 does not appear in this draft. The IESG has decided to have no problem with the publication of this draft, but I would still personally strongly suggest that the text in question should be fixed.

More specifically, shouldn't this document have the same kind of additions done as we did for RFC 6267? E.g., the latter says:

  With the self-expiration of the public identities,
  the traditional real-time validity verification and revocation is not
  required.  For example, if the public identity is bound to one day,
  then, at the end of the day, the Public/Private Key pair issued to
  this peer will simply not be valid anymore.  Nevertheless, just like
  with Public-Key-based certificate systems, if there is a need to
  revoke keys before the designated expiry time, communication with a
  third party will be needed.

but the current draft says:

  With the self-expiration
  of the private keys, the traditional real time validity verification
  and revocation is not required.

[Ballot discuss]
Shouldn't this document have the same kind of additions done as we did for RFC 6267? E.g., the latter says:

  With the self-expiration of the public identities,
  the traditional real-time validity verification and revocation is not
  required.  For example, if the public identity is bound to one day,
  then, at the end of the day, the Public/Private Key pair issued to
  this peer will simply not be valid anymore.  Nevertheless, just like
  with Public-Key-based certificate systems, if there is a need to
  revoke keys before the designated expiry time, communication with a
  third party will be needed.

but the current draft says:

With the self-expiration
  of the private keys, the traditional real time validity verification
  and revocation is not required.

[Ballot discuss]
I agree with Adrian and Robert that the current IESG Note is confusing and I'm not sure what we're trying to say in it. That said, I'm also a bit concerned that this document *is* trying to extend IETF protocol (EAP?) and therefore should go through IETF process. It sounds like we suspect that IETF Review would fail to garner consensus, but that's not a reason to give the ISE a go-ahead. I may be confused on the meaning of 5742 in this regard, so I'd like to discuss.

[Ballot discuss]
The additional note in the proposed response doesn't make sense for an ISE document.

Based on conversations with Sean, it was based on a similar note placed in an IETF stream document.

The boilerplate for the ISE stream documents will already say:

  Independent Stream:
      "This is a contribution to the RFC Series, independently of any
      other RFC stream.  The RFC Editor has chosen to publish this
      document at its discretion and makes no statement about its value
      for implementation or deployment."

The current proposed additional note ("Due to its specialized nature, this document
experienced limited review within the IETF.") implies that there was some IETF review
beyond the 5742 review for conflict, and could imply that _other_ documents get more
IETF review. These documents get no such IETF review beyond the conflict review called
out in RFC 5742.

[Ballot comment]
- I agree with the proposed IESG note, but I guess we need to
figure out (with the ISE?) how to properly state that.

- another case where the IPR declaration refers to a "standard"
but this isn't going to be one.

- section 1, Public key protocols do not require "large scale" PKI,
as clearly demonstrated by the success of ssh. The statement is
incorrect.

- section 1, No evidence is give for the assertion that a PKG is
"simple." Personally, I doubt that and the word's not needed in
any case. Suggest s/simple//

- section 1, Many IBE schemes have claimed that including dates
in names avoids revocation issues. However, afaik, no one has
actually done this in the wild so this claim is also just a
bare assertion since the usability issues related to this idea
are essentially untested.

- section 2.1, IBE does not allow a public key to be calculated from
an identity. IBE requires an identity *and* a set of PKG parameters
in order to generate a public key. Truth-in-advertising would be
better here.

- Its not clear to me that two implementations of this would
interoperate. That may or may not be the case, but I guess
additional specification would be required. It would be good
to say more about what'd be needed for that.

- Its not really possible to evaluate the security claims of
this protocol as part of a 5742 review. It'd be good if a
statement to that effect were included. I'm not doubting the
security claims, but they have not been exposed to wide
spread review which would be needed were something like this
to come out of the IETF track.

- Its hard to see how 2119 is the only normative reference
here.

- typo: s/Privet/Private/

[Ballot discuss]
Before moving to No Objeciton, I would like to spend time on the call Discussing the proposed IESG note on the basis that this is not an IETF document (coming through the ISE) and so it would not be expected that it received any IETF review compared to other Informational RFCs. Furthermore, ISE documents normally carry a standard disclaimer that "this is not the work of the IETF"

I suppose my point is: what message is the IESG note trying to send?

[Ballot discuss]
I would like to spend time on the call Discussing the proposed IESG note on the basis that this is not an IETF document (coming through the ISE) and so it would not be expected that it received any IETF review compared to other Informational RFCs. Furthermore, ISE documents normally carry a standard disclaimer that "this is not the work of the IETF"

I suppose my point is: what message is the IESG note trying to send?

The draft draft-cakulev-ibake-04.txt
is ready for publication from the Independent Stream.
Please ask IESG to review it, as set out in RFC 5742.

The following is some background for this draft, please forward it
to IESG along with this request ...

This draft's abstract says:
"Cryptographic protocols based on public key methods are based on
certificates and large scale public key infrastructure (PKI) to
support certificate management. The emerging field of Identity Based
Encryption protocols allows to simplify the infrastructure
requirements via a Private-key Generator (PKG) while providing the
same flexibility. However one significant limitation of Identity
Based Encryption methods is that the PKG can end up being a de-facto
key escrow server with undesirable consequences. Another observed
deficiency is a lack of mutual authentication of communicating
parties. Here, Identity Based Authenticated Key Exchange (IBAKE)
Protocol is specified which does not suffer from the key escrow
problem and in addition provides mutual authentication and a perfect
forward and backwards secrecy."

It was reviewed by Jim Schaad, who pointed out two typos:
Section 3.2
OLD
o The Responder selects a random y and computes yP. The Responder
MUST use a fresh, random value for x on each run of the protocol
NEW
o The Responder selects a random y and computes yP. The Responder
MUST use a fresh, random value for y on each run of the protocol
i.e. substitute y for x (!)

and s/Privet Key/Private Key/

I'll ask the authors for a new version to fix those, as well as to
address any IESG comments that may arise.


Thanks, Nevil (ISE)