Subject: [Pppext] Re: your ECP-QKD draft

From: Mohamed Ali SFAXI <[email-masked]>
Date: Thu, 13 Oct 2005 14:03:13 +0200

Dear James Carlson,

Thank you for your comments here is our answer :

How:

To exchange the quantum key , both nodes must have some special features 
(quantum devices) or simply a quantum modem (these modems like are 
already sold by some companies such as IdQuantique (www.idquantique.com) 
and MagiQ (http://www.magiqtech.com/))

Here are some requirements to perform a quantum key distribution:

a- An optical channel: the optical channel is the physical link between 
two adjacent nodes. Nowadays, there are two means able to carry a 
quantum cryptography transmission: the optical fibber or the free space 
(the air) [6]. As the quantum cryptography uses photons to encode the 
information no other channel could be used up to now. However, as the 
quantum physics are experimenting the use of atoms and electrons as a 
quantum particle [7, 5] maybe other kind of channel could be used in the 
future.

b- A Q3P modem: this modem has to polarize, send and detect photons; it 
has to include a photon detector and a laser with a single photon 
emitter and photon polariser. The source and the detector are widely 
commercialised and many techniques are employed1. However, these devices 
are used to exchange the quantum key but could also used to send and 
receive simple data depending on how encoding the information. The modem 
in this case is a simple optical fiber modem.

c- QKD protocol: in order to establish an unconditional secure key, a 
quantum key distribution protocol is needed. This protocol must be 
implemented in the Q3P modem. The protocol will deliver a secure key 
after distilling the key and error correction [3]. The key is stored in 
a flash buffer memory and used when enciphering the data. The QKD 
protocols BB84 and B92 [1, 2] are nowadays the quantum cryptographic 
protocols widely used. These protocols are securely proven and largely 
experimented [4].

Why:

All encryption algorithms used in PPP assume that there is an already 
shared secret between the two nodes as cited in [RFC2419]: "The means by 
which the secret becomes known to both communicating elements is beyond 
the scope of this document; usually some form of manual configuration is 
involved". We don't know how this key is generated, shared nor installed 
in the PPP devices.

Using the Q3P (and especially the QKD), we solve all the secure key 
exchange problems. In fact, we could exchange an unconditional secure 
key, on-demand and dynamically.

What might be done by this key :

- can be used for instance in DESE  [RFC2420] as the "initial nonce".

- Can also be used in other encryption algorithms such as "One Time Pad" 
function which need a new key for each message

 

References:

1. Bennet, C; Brassard, G (1984). IEEE International Conference on 
Computers, Systems, and Signal Processing. IEEE Press, LOS ALAMITOS

2. Bennet, (1992). C Quantum Cryptography: Uncertainty in the Service of 
Privacy. Science 257.

3. Gisin, N; Ribordy, G; Tittel, W; Zbinden, H. (2002). "Quantum 
Cryptography". Reviews of Modern Physics 74

4 Guenther, C (2003) "The Relevance of Quantum Cryptography in Modern 
Cryptographic Systems". GSEC Partical Requirements (v1.4b). 
http://www.giac.org/practical/GSEC/Christoph Guenther GSEC.pdf

 5. Knight, P (2005). "Manipulating cold atoms for quantum information 
processing". QUPON conference Vienna 2005.

6. R.Hughes,J.Nordholt,D.Derkacs,C.Peterson, (2002). "Practical 
free-space quantum key distribution over 10km in daylight and at night". 
New journal of physics 4 (2002)43.1-43.14.

7. Tonomura, A (2005). "Quantum phenomena observed using electrons". 
QUPON conference Vienna 2005.

*Mohamed Ali SFAXI*
Assistant Diplômé
Inforge - HEC
University of Lausanne
tel. + 4121 692 34 22

Website : http://www.hec.unil.ch/sfaxi/

James Carlson wrote:

>This is currently being discussed on [email-masked].  I encourage you
>to participate in the discussion.
>
>The current concern is that the draft appears to have an explicit key
>exchange (as part of the negotiation), but that the draft doesn't
>explain how or why this key exchange exists, or what might be done
>with those keys.  (Clearly, they cannot be used for ECP, as they've
>already been exposed to attackers by the negotiation itself.)
>
>Because of the lack of clarity in the specification, it seems likely
>that the consensus will be to deny the request for a new ECP code
>point, unless you can successfully argue your case.
>
>  
>
_______________________________________________
Pppext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pppext

---

From: James Carlson <[email-masked]>
Date: Thu, 13 Oct 2005 09:17:37 -0400

> and MagiQ (http://www.magiqtech.com/))

Yes, understood.

However, none of the explanation you've offered actually addresses the
questions I've asked.  Please examine this feature from your proposed
draft:

>     To establish and configure the quantum key distribution between 
>     the two nodes, it is necessary to exchange some data between 
>     them. We propose a specific ECP packet format to carry QKD 
>     parameters (Figure 2):
> 
> 
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |     Type      |    Length     |  Key-Length
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |     TTL     |T|    
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
[...]
>     Length field:
>     The length is number of octets in the packet and it is more than 
>     ”5” octets (1 octet for the type, 1 octet for the packet length, 
>     2 octets for the key length and one octet for the TTL and the T 
>     field).

This appears to describe a new option for ECP that exchanges keys
between the peers, and does the exchange in the clear.

Why does it do that?  What does it have to do with quantum key
exchange?

Moreover, the draft does not explain how the key to be used with the
chosen algorithm is actually derived, nor what algorithms are
possible, so there's essentially no hope of interoperability.  As IETF
documents have the explicit goal of producing interoperable
implementations, this draft falls short of what's needed.

-- 
James Carlson, KISS Network                    <[email-masked]>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

---

From: Vernon Schryver <[email-masked]>
Date: Thu, 13 Oct 2005 08:22:37 -0600 (MDT)

> From: Mohamed Ali SFAXI <[email-masked]>
> To: James Carlson <[email-masked]>
> Cc: [email-masked], [email-masked]

> Thank you for your comments here is our answer :

Your answer is not responsive.

Perhaps the best way to answer the objections to the I-D and the
proposed IANA registry would be for you to build a complete prototype
implementation of the idea or at least a design complete in all
aspects.  Given your claim that quantum cryptography is a settled
technology (never mind http://www.idquantique.com/news/files/june-05.pdf ),
it should be easy to make a complete design including writing software.
You could base such an effort on one of the open-source implementations
of PPP with encryption and add whatever is needed to work with your
quantum encryption hardware.  You would not need to buy quantum
cryptography hardware but could write code to specifictions obtained
from id Quantique or MagiQ.

> To exchange the quantum key , both nodes must have some special features=20
> (quantum devices) or simply a quantum modem (these modems like are=20
> already sold by some companies such as IdQuantique (www.idquantique.com)=20

As far as PPP is concerned, exactly the same is true of any use of 
PPP encryption.  In general one does not change PPP when one uses
new kinds of modems.

> a- An optical channel: the optical channel is the physical link between=20
> two adjacent nodes. Nowadays, there are two means able to carry a=20
> quantum cryptography transmission: the optical fibber or the free space=20
> (the air) [6]. As the quantum cryptography uses photons to encode the=20
> information no other channel could be used up to now. However, as the=20
> quantum physics are experimenting the use of atoms and electrons as a=20
> quantum particle [7, 5] maybe other kind of channel could be used in the=20
> future.

That fact does not affect PPP, and does not answer the questions
that have been raised about your I-D.

> b- A Q3P modem: this modem has to polarize, send and detect photons; it=20
> has to include a photon detector and a laser with a single photon=20
> emitter and photon polariser. The source and the detector are widely=20
> commercialised and many techniques are employed1. However, these devices=20
> are used to exchange the quantum key but could also used to send and=20
> receive simple data depending on how encoding the information. The modem=20

That also does not affect PPP, and does not answer the questions raised
about your I-D.

> c- QKD protocol: in order to establish an unconditional secure key, a=20
> quantum key distribution protocol is needed. This protocol must be=20
> implemented in the Q3P modem. The protocol will deliver a secure key=20
> after distilling the key and error correction [3]. The key is stored in=20
> a flash buffer memory and used when enciphering the data. The QKD=20
> protocols BB84 and B92 [1, 2] are nowadays the quantum cryptographic=20
> protocols widely used. These protocols are securely proven and largely=20
> experimented [4].

That also has nothing to do with PPP.  Never mind that I disagree with
the claim that anything about quantum cryptography is settled technology.
Except that the encryption key is negoiated with quantum cryptography,
that description fits existing PPP encryption implementations.

In fact, your description fits existing PPP implementations better
than a system involving quantum cryptography, because I doubt that one
would want to store keys negotiated with quantum cryptogrpah in a flash
buffer memory.

> Why:
>
> All encryption algorithms used in PPP assume that there is an already=20
> shared secret between the two nodes as cited in [RFC2419]: "The means by=20
> which the secret becomes known to both communicating elements is beyond=20
> the scope of this document; usually some form of manual configuration is=20
> involved". We don't know how this key is generated, shared nor installed=20
> in the PPP devices.
>
> Using the Q3P (and especially the QKD), we solve all the secure key=20
> exchange problems. In fact, we could exchange an unconditional secure=20

Yes, but that has nothing to do with PPP itself.

well, I'm not quite right.  Anyone who understands PPP sees an opportunity
to write a real I-D saying when to use quantum cryptography to negoiate
a new key PPP encryption key based on certain PPP state changes.  That
would not involve a change to PPP beyond a pause for obtaining new
random numbers (keys) and negotiating exchanging them over the (presumably
relatively slow) quantum cryptography channel before continuing PPP
as usual.

> - Can also be used in other encryption algorithms such as "One Time Pad"=20

The only positive way I understand that statement is as proposing to
use quantum cryptography not exchange keys before IPCP starts but to
carry all PPP bits.  As such it still has nothing to do with PPP,
because you are proposing a new channel above which would be PPP. 
In other words, do MagiQ (http://www.magiqtech.com/) and id Quantique
(http://www.idquantique.com/) agree with your claim that PPP must be
changed to use their modems?

PPP often does not change to use new kinds of conventional modems.

Vernon Schryver    [email-masked]

---

From: Mohamed Ali SFAXI <[email-masked]>
Date: Fri, 14 Oct 2005 15:23:15 +0200

Dear All,

James Carlson wrote:

>>    ?5? octets (1 octet for the type, 1 octet for the packet length, 
Yes

>Why does it do that?  What does it have to do with quantum key
In order to have a valid key, we need some negotiation before. The 
negotiation is done thanks to ECP. The two peers have to agree on the 
key length, TTL and perhaps additional option not described in our draft.
when these parameters are fixed, a QKD starts. This is done out of the 
PPP mechanism (i.e using Q3P modems). We mentioned it in the draft to 
show that the network phase will start after the key is shared.
after that, the key is delivered to the network phase to encrypt data

>implementations, this draft falls short of what's needed.
We didn't propose any encryption algorithm that could be used because 
all the encryption algorithms that are already recognized by PPP could 
be used. In fact, we have  introduced only a new way to obtain the 
encryption key. I think that our draft do not harm the interoperability.

Best regards,

*Mohamed Ali SFAXI*
Assistant Diplômé
Inforge - HEC
University of Lausanne
tel. + 4121 692 34 22

---

From: Mohamed Ali SFAXI <[email-masked]>
Date: Fri, 14 Oct 2005 15:36:42 +0200

Dear All,

>from id Quantique or MagiQ.

We are already in contact with Idquantique and maybe we will propose 
something togother.

>PPP encryption.  In general one does not change PPP when one uses

You are right. However, the question was how to exchange the key so I 
answered to that question.

>that have been raised about your I-D.

Same thing

>That also does not affect PPP, and does not answer the questions raised

Same thing

>Vernon Schryver    [email-masked]

Our idea was to create some kind of ECP negotiation to fix the key 
exchange parameters and then start the QKD to share a secret key, So it 
is normal that the existing PPP implementations fits well. The only 
difference is that to start the network phase using an encryption 
algorithm we can choose to use the QKD to share a secret key or to 
assume that the key is already shared (i..e what is done now in PPP).

Best regards,

*Mohamed Ali SFAXI*
Assistant Diplômé
Inforge - HEC
University of Lausanne
tel. + 4121 692 34 22

---

From: James Carlson <[email-masked]>
Date: Fri, 14 Oct 2005 09:54:57 -0400

Mohamed Ali SFAXI writes:
> key length,

The key length and how the key bits are manipulated is intimately tied
with the encryption algorithm chosen.  This is why I keep asking about
that problem.

For example, if you use 3DES (RFC 2420), you need three 56-bit
subkeys, each of which is normally stored in an 8-octet block, with
the 8 LSBs ignored (used as parity).  So, one plausible transform
would be to take exactly 24 octets from the quantum stream, and use
them directly as the three keys (k1, k2, and k3).  To do this, you
need to wipe out the LSBs (for use as parity) and reject any weak key
proposed by your peer.

But that's only *ONE* plausible transform among many, and it seems to
assume that the quantum stream itself is error-free.  If each
implementation chooses to do this a different way, you'll end up with
chaos.  It won't be interoperable.

Furthermore, once you've chosen the algorithm, at least in this case,
you no longer have the option of negotiating the key length.  The
algorithm dictates it.

In addition to that, the TTL appears to be unnecessary.  The simplest
way to deal with key expiry is to renegotiate ECP itself.  Why isn't
that the chosen method?

Or, if you can change the key on the fly without restarting ECP, then
why not just do it?  Why must the peers agree on this parameter at
all?

If it's a useful feature, wouldn't a key TTL be something that's
generally helpful for ECP, rather than a specific issue with quantum
key exchange?

> TTL and perhaps additional option not described in our draft.

Please explain the "additional option," or at least the intended
behavior.  How do we get interoperability if we have features that
aren't documented?

> after that, the key is delivered to the network phase to encrypt data

I don't see how this requires any special negotiation.

Obviously, you must have prior arrangement to use these "Q3P modems"
on the two consenting peers.  Why is that by itself not sufficient to
indicate that this new key source is desired?  Why must the peers also
negotiate something that they already know to be true?

> encryption key. I think that our draft do not harm the interoperability.

See above.  That choice is an interoperability problem.

---

From: Vernon Schryver <[email-masked]>
Date: Fri, 14 Oct 2005 09:21:52 -0600 (MDT)

> In order to have a valid key, we need some negotiation before. The=20
> negotiation is done thanks to ECP. The two peers have to agree on the=20

Your words "perhaps additional option not described in our draft" would
demand that your draft be rejected by the IESG until it is complete.

Have you read the RFCs on how to publish an I-D?

> when these parameters are fixed, a QKD starts. This is done out of the=20
> PPP mechanism (i.e using Q3P modems). We mentioned it in the draft to=20

Again, that seems to have nothing to do with QKD in particular.

> We didn't propose any encryption algorithm that could be used because=20
> all the encryption algorithms that are already recognized by PPP could=20
> be used. In fact, we have  introduced only a new way to obtain the=20

Until and unless your draft does something to help interoperability,
the IESG should to reject it.  Guessing that some as yet unknown ECP
negotiations might be needed for QKP does not justify an RFC or
an IANA type assignment.

] From: Mohamed Ali SFAXI <[email-masked]>

] We are already in contact with Idquantique and maybe we will propose 
] something togother.

It would be wise to withdraw now and return later when you have something
of substance to propose.

]>>Here are some requirements to perform a quantum key distribution:

] >As far as PPP is concerned, exactly the same is true of any use of=20
] >PPP encryption.  In general one does not change PPP when one uses
] >new kinds of modems.
]
] You are right. However, the question was how to exchange the key so I=20
] answered to that question.

I do not recall that anyone asked how quantum cryptography works
or how it might be used in a vague, hand waving theory to exchange
keys.  Perhaps you did not realize that people interested in moving
encrypted or otherwise secure data over long distances might already
be as aware of QKD as you seem to be.

More important, your document fails to specify how to exchange keys
using quantum crypography.  I suspect that there is more than one way,
and that some sort of negotiating might be useful.  That negotiating,
if needed, sounds like an appropriate subject of an RFC.  However,
your draft of an I-D does not in any way address such issues.

] >>Here are some requirements to perform a quantum key distribution:

] >That fact does not affect PPP, and does not answer the questions
] >that have been raised about your I-D.
]
] Same thing

Telling us things we already know about QKD does not answer questions
about you draft of an I-D.

] >>b- A Q3P modem: this modem has to polarize, send and detect photons; it=

] >That also does not affect PPP, and does not answer the questions raised
] >about your I-D.

] Same thing

Why do you assume we know nothing of quantum cryptography?

] >PPP often does not change to use new kinds of conventional modems.

] Our idea was to create some kind of ECP negotiation to fix the key=20
] exchange parameters 

According to your own words about possible additional options, your
draft of an I-D fails to do that.

]                                                                 So it=20
] is normal that the existing PPP implementations fits well. The only=20
] difference is that to start the network phase using an encryption=20
] algorithm we can choose to use the QKD to share a secret key or to=20
] assume that the key is already shared (i..e what is done now in PPP).

You do not need a special negotiation for QKD PPP to do that.  When
you install the quantum cryptography modems, you must configure them
and rest of your PPP machinery to use them.  Part of that installation
procedure can involve setting the parameters that are pecular to QKD.
Parameters that are common to other ECP schemes do not need a QKD RFC.
It might be that QKD will need some PPP negotiations, but they cannot
be standardized before they are specified.

You persist in not answering the question of how QKD differs from
plain old telephones for key distribution as far as PPP and ECP are
concerned.

This is all supposed to be about assigning an ECP type number to BB84.
I've been told by people actually working on quantum cryptography and
quantum computing that BB84 is an extremely unlikely choice.  Actually,
the words they used about this whole proposal were a lot stronger.

This should be rejected until something is actually proposed (i.e.
without any TBD holes for possible additional parameters) and with
support from people actually working with QKD.  It would be wrong to
tie the hands of people working on QKD by advancing something that is
only a place keeper.

---

From: James Carlson <[email-masked]>
Date: Fri, 14 Oct 2005 13:09:48 -0400

Bill Manning writes:
> a couple of things here:
> 
> 
> the I-D is in the DB at
> https://datatracker.ietf.org/public/idindex.cgi? 
> command=view_related_docs&id=13770
>   but clicking on the "view document" link gets nothing!

The only extant version of the document that I know of is the one that
IANA forwarded to the pppext list.

We asked specifically for a draft to review.  I don't know why the
submitter wasn't told to go through the normal I-D submission process,
but I'm guessing that either they didn't do it, or the publishing
process somehow failed.

In any event, we got the text we were asking about, so I'm less
concerned about the publication process.  We can revisit that issue
later _if_ anything substantive comes out of the discussion.

(Since I don't expect there to be any positive consensus on this
document, I'm a bit reluctant to raise their expectations by telling
the authors to jump through the I-D hoop first.  It's not as though
I-D publication is 'trivial' anymore.  :-<)

---

From: Mohamed Ali SFAXI <[email-masked]>
Date: Mon, 17 Oct 2005 13:40:42 +0200

Dear All,

>I-D publication is 'trivial' anymore.  :-<)

We asked the IANA for a new type number and the IANA told us to publish 
an I-D first. We have already submit our I-D according to the normal I-D 
submission process. I don't know why the web link doesn't work !!

>
> Bill Manning wrote: a couple of things here:
>
>
>
> the I-D is in the DB at
> https://datatracker.ietf.org/public/idindex.cgi?command=view_related_docs&id=13770 
>
> and one of my quantum computing cohorts makes this comment:
>
> >Mr. Sfaxi either misunderstands or fails to explain one VERY important
> >point: QKD REQUIRES an authenticated classical channel to operate
> >securely. Such a channel involves either PKI or a pre-shared secret.
> >

It is possible to have only one channel for the quantum communication 
and for the classical communication. It is feasible (confirmed by 
IdQuantique). IdQuantique and MagiQ use separate modules for quantum 
communication and classical communication in their devices to improve 
the QKD performances and because easy to implement that's why they use 
two different channels (in my opinion).

> >See
> >http://rdvlivefromtokyo.blogspot.com/2005/10/stop-myth-qkd-doesnt-fix-what-shor.html 
>
> >http://dabacon.org/pontiff/?p=1086
> >and especially
> >http://arxiv.org/abs/quant-ph/0406147
> >
> >As to id-quantique and MagiQ Technologies, they have been around for a
> >couple of years. I don't know anyone who has actually purchased and
> >used their equipment. If you know anyone who has, please ask them to
> >contact me; I would love to find out about their experiences!
> >
> >Feel free to forward this to the reflector, and include me on any
> >replies or further conversations, but I don't read pppext.
> >
> > --Rod
>

>you no longer have the option of negotiating the key length.  The
Negotiating the key length is a feasible way to be independent from the 
encryption algorithm and to use the QKD for new algorithms and other 
encryption mechanisms like the one-time-pad function.

>generally helpful for ECP, rather than a specific issue with quantum
We have to use TTL for two reasons :

- security purpose (to have the possibility to refresh encryption key often)

- as we use the link as the quantum channel and the classical channel 
the classical communication must stop (when the TTL expires) and the 
quantum communication starts.

>behavior.  How do we get interoperability if we have features that
"additional option" for us is a way to negotiate new QKD parameters. 
This field is not used now but could be used if required by users and we 
think that we may need a free field for the future use.

> -- James Carlson, KISS Network <[email-masked]> Sun 
> Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS 
> UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
>

>Have you read the RFCs on how to publish an I-D?

As we said above : "

"additional option" for us is a way to negotiate new QKD parameters. 
This field is not used now but could be used if required by users and we 
think that we may need a free field for the future use.

"

>your draft of an I-D does not in any way address such issues.
The QKD negotiation depends mainly on the QKD protocols. We assume that 
the modems and the software in these modems are the only concerned by 
the negotiation. I completely agree with you to have a common 
negotiation way in QKD.

>Why do you assume we know nothing of quantum cryptography?
I don't assume that but I presented what we need to use quantum 
cryptography.

>draft of an I-D fails to do that.
please see above

>plain old telephones for key distribution as far as PPP and ECP are
The QKD is a solution to distribute keys.  We try to have an automatic  
"on-line" way to share the secret key. We choose the QKD as it is an 
unconditional secure mechanism to distribute secret. We need the ECP to 
configure this exchange (not physical configuration but logical 
configuration).

>tie the hands of people working on QKD by advancing something that is

We propose the BB84 as it is the initial QKD protocol and the most 
famous. In addition, BB84 is still used by MagiQ and IdQuantique.

*Mohamed Ali SFAXI*
Assistant Diplômé
Inforge - HEC
University of Lausanne
tel. + 4121 692 34 22

---

From: Vernon Schryver <[email-masked]>
Date: Mon, 17 Oct 2005 08:10:21 -0600 (MDT)

> Negotiating the key length is a feasible way to be independent from the=20
> encryption algorithm and to use the QKD for new algorithms and other=20

That not only does not address the point, it is wrong.

For example, to use a one-time pad, it would be necessary to specify
which pad, where you start using it, and how you use it.  Do you
use bit-wise XOR or something else such as byte-wise addition?
Is the idea is to XOR a stream of random bits carried on the quantum
channel with the bits on a conventional channel?  Perhaps you would
do that because the quantum channel is slow but runs continuously but
you'd run the conventional channel only there are PPP bits to carry.
But in that case, which bits on the conventional channel are encrypted?
link layer framing? LCP? I assume not ECP, but is that right?

In checking the draft to see if it says anything on that issue, I
noticed the T field which is defined as

     The T field specifies if the TTL field concerns the number of
     messages or the amount of time. If the value is 1, the TTL 
     field corresponds to the amount of time in second. If it is 0, 
     the TTL is the number of messages per key.
 
What is a "message"?  Is it a PPP packet for any NCP or something
else?  Are any PPP packets not counted, such as ECP packets carrying
TTL and T fields?  Or is a message a fixed block of bits or something 
else understood by the QKD modems and not known to PPP?

What, if any state change happens in the ECP state machine when the
TTL expires?

> "additional option" for us is a way to negotiate new QKD parameters.=20
> This field is not used now but could be used if required by users and we=20

That does not answer the question of how to interoperability might
be achieved when there are unspecified additional parameters somewhere
on the fiber.

> "additional option" for us is a way to negotiate new QKD parameters.=20
> This field is not used now but could be used if required by users and we=20

So that's why the diagram on page 4 just trails off.  I thought it was
a mere editoral problem.  It is instead intentional.  Implementors are
supposed to pick whatever length they like and need, and interoperability
be hanged.

Enough of this waste time of time.

---

From: Bill Manning <[email-masked]>
Date: Fri, 14 Oct 2005 09:54:01 -0700

a couple of things here:

the I-D is in the DB at

On Oct 14, 2005, at 6:23, Mohamed Ali SFAXI wrote:

>  Dear All,
>
>  James Carlson wrote:Mohamed Ali SFAXI writes:
>>
>>>     �5� octets (1 octet for the type, 1 octet for the packet length,
>  when these parameters are fixed, a QKD starts. This is done out of  
> the PPP mechanism (i.e using Q3P modems). We mentioned it in the draft  
> to show that the network phase will start after the key is shared.
> Mohamed Ali SFAXI

---

From: Rod Van Meter <[email-masked]>
Date: Mon, 17 Oct 2005 22:18:11 +0900

> The QKD negotiation depends mainly on the QKD protocols. We assume
> that the modems and the software in these modems are the only
> concerned by the negotiation. I completely agree with you to have a
> common negotiation way in QKD.

But there is a great deal more to negotiate about a QKD exchange than I
see specified in your document.

A quick glance at http://arxiv.org/abs/0503058/ shows at least the
following levels of the protocol that must be software-selected; I
believe the selection must be the same at both ends, therefore, they
seem like good candidates for a negotiation (and getting that
negotiation right so that a man in the middle can't "dumb down" the
protocol and create a vulnerability to exploit would be the fun and
tricky part):

* Authentication (BBN has implemented two methods)
* Privacy amplification (one method so far)
* entropy estimation (four methods) (this might be local info only, not
sure)
* error detection and correction (two methods)
* sifting (two methods)

That's just what BBN has implemented so far, and I know there are
further methods for various portions of the protocol.  There are dozens
-- maybe a hundred -- good papers on QKD, many of which propose some
slight variant to the protocol that enhances some characteristic that
the authors care about.  Many of those will ultimately fall by the
wayside (some will be *shoved* aside -- QKD researchers, like security
researchers everywhere, delight in attempting to prove each other
wrong), but some will ultimately be negotiable parameters.

> famous. In addition, BB84 is still used by MagiQ and IdQuantique. 

Indeed, somewhat to my surprise, it does seem that both are still using
BB84.  Bennett92 requires the creation of only two polarized states,
compared to BB84's four, so it would seem that it should be easier to
implement in hardware, but I'm not building it, so what do I know?  Some
of the further, more modern variants I'm less familiar with.  BBN also
is using BB84 at the moment, but claims to be working on newer protocols
(B92? Lo-Chau?).  I'm not sure which, if either, is actually more
bandwidth- or photon-efficient.

This choice will be made by the modem hardware (actually, modem is a
misnomer, but we'll work with it), and will probably be as fundamentally
unchangeable as the wavelength (though even here I could be wrong, given
flexible enough hardware).  I know the modems have to be "trained up" to
match corresponding states, and I know that has to be repeated on a
regular basis because phases drift with the temperature of the fiber.  I
don't know if there is a need for a classical control protocol here, or
if it's all handled in-band (e.g., by simply selecting some of the bits
as state maintenance bits).

It should be obvious that I know quite a bit about QKD.  It should be
equally obvious that I know nowhere near enough to write an RFC about
how to control it and integrate it with either IPSEC or PPP.  If it were
me, I would leave this to the folks actually doing the work -- or,
perhaps, attempt to create an alliance with them to co-write it, if they
are able to contribute technically but lack either the time or
proficiency to generate the complete RFC by themselves.  RFCs should be
written by the people doing the work; even the proxy method I just
described is a poor substitute for it.

		--Rod

---

From: James Carlson <[email-masked]>
Date: Mon, 31 Oct 2005 07:52:24 -0500

Last call for consensus: it seems to me that the general agreement
I've seen on the list so far is that the draft as specified lacks
sufficient information to produce interoperable implementations and
does not appear to be relevant for PPP ECP.

If this is inaccurate, please let me know.  Otherwise, I'll report
back to ICANN/IANA stating that we do not believe the assignment
should be granted.