Subject: [Pppext] [rt.icann.org #3528] FW: General Request for Assignments (ppp-numbers)

From: "Michelle Cotton via RT" <[email-masked]>
Date: Mon, 10 Oct 2005 11:44:51 -0700 (PDT)

PPPEXT Working Group:

This is a follow-up to a recent request you were reviewing for IANA.
The Working Group Chair requested that the group wanted to see the I-D 
before making a decision.  Below, please find the I-D sent to IANA by 
the requestor.

We will await your response.

Thank you,

Michelle Cotton
IANA

****************************************************************

As requested, please find the I-D about our PPP extension. It is called 
"Quantum Key Destribution within Point to Point Protocol (Q3P)" written 
by Solange Ghernaouti-Hélie and Mohamed Ali Sfaxi.

> Network Working Group                       Solange Ghernaouti-Hélie
> INTERNET-DRAFT                           		   Mohamed Ali 
Sfaxi
> 							    University 
of Lausanne
> Expires: April, 29 2006					        
October 2005 
> 
> 
> 
> 	      Quantum Key Destribution within Point 
> 			  to Point Protocol (Q3P)
> 		  draft-ghernaouti-sfaxi-ppp-qkd-00.txt
> 
> 
> Status of this Memo
> 
>    By submitting this Internet-Draft, we certify that any applicable
>    patent or other IPR claims of which we are aware have been 
disclosed,
>    or will be disclosed, and any of which we become aware will be
>    disclosed, in accordance with RFC 3668.
> 
>    Internet-Drafts are working documents of the Internet Engineering
>    Task Force (IETF), its areas, and its working groups.  Note that
>    other groups may also distribute working documents as
>    Internet-Drafts.
> 
>    Internet-Drafts are draft documents valid for a maximum of six
>    months and may be updated, replaced, or obsoleted by other
>    documents at any time.  It is inappropriate to use Internet-Drafts
>    as reference material or to cite them other than as "work in
>    progress."
> 
>    The list of current Internet-Drafts can be accessed at
>    http://www.ietf.org/1id-abstracts.html
> 
>    The list of Internet-Draft Shadow Directories can be accessed at
>    http://www.ietf.org/shadow.html
> 
> 
> Abstract
> 
>    The aim of this paper is to analyse the use of quantum
>    cryptography within PPP. We propose a solution that integrates 
>    quantum key distribution into PPP. 
> 
> 
> Terminology
> 
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 
>    NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and 
>    "OPTIONAL" in this document are to be interpreted as described in 
>    RFC 2119 [9].
> 
> 
> 
> 
> 
> 
> Ghernaouti and Sfaxi                                        [Page 1]
> 
> INTERNET-DRAFT                               Expires: April, 29 2006
> 
> 
> 
> 1. Introduction
> 
>    The point to point protocol (PPP) [RFC1661] is a data-layer 
>    protocol ensuring a reliable data exchange over a point to point 
>    link. When the connection is established and configured, the PPP 
>    allows the data transfer of many protocols (IP, IPX, AppleTalk). 
>    That's why; PPP is widely used in Internet environment.
> 
>    The unique security of PPP as specified in the RFC 1661 is limited 
>    to the authentication phase. The two nodes use an authentication 
>    protocol such as Password Authentication Protocol (PAP) [RFC1334] 
>    or Challenge Handshake Authentication Protocol (CHAP)[RFC1994]. In 
>    1996, Meyer published an additional security protocol for PPP 
>    called ECP (Encryption Control Protocol) [RFC1968]. This protocol 
>    allows the use of the encryption in PPP frame. The ECP gives the 
>    possibility to select the encryption algorithm and its parameters. 
>    This ensures the confidentiality and the integrity of the PPP 
>    frame. The weakness of this use resides in the way of generating 
>    and exchanging the encryption key. In fact, for all the encryption 
>    algorithms the secret key is assumed to be already shared between 
>    the communicating parties. So to enhance security, we propose the 
>    use of quantum cryptography to generate and to share the secret 
>    key between the two nodes.
> 
>    Quantum cryptography is the only method allowing the distribution 
>    of a secret key between two distant parties without transmitting 
>    any secret over unsecure channel [1, 4]. the emitter and the 
>    receiver will be able to share an encryption key for enciphering 
>    confidential data. The secrecy of this shared key is 
unconditional  
>    [8] by the fact that the secret is generated and exchanged based 
>    on physic laws (instead of mathematical functions). Thats why we 
>    propose to integrate the quantum key distribution (QKD) process to 
>    share secret key between two nodes.
> 
> 
> 2. Encryption Control Protocol (ECP) for Quantum Key Distribution 
>    (QKD)
> 
>    The Encryption Control Protocol (ECP) defines the negotiation of
>    the encryption over PPP links. After using LCP to establish and 
>    configure the data link, the encryption options and mechanisms 
>    could be negotiated. The ECP packets exchange mechanism is nearly
>    the same as the LCP mechanism. The ECP packets are encapsulating 
>    into PPP frame (a packet per frame). The type is 0x8053 to 
>    indicate the Encryption Control Protocol. Two additional messages 
>    are added to the code field: the Reset-Request and Reset-Ack 
>    message. These two messages are used to restart the encryption 
>    negotiation. An encrypted packet is encapsulated in the PPP 
>    information field where the PPP protocol field indicates type 
>    0x0053 (encrypted datagram). The ECP packet is presented in 
>    figure 1
> 
> 
>     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     |  Values...
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> 
>       Figure 1 - The Encryption Type Configuration Option format
> 
> 
> Ghernaouti and Sfaxi                                         [Page 2]
> 
> 
> INTERNET-DRAFT                                Expires: April, 29 2006
> 
> 
>    ECP packet, the type represents the encryption protocol option to
>    be negotiated (for instance type 1 is DES encryption). The number 
>    of octets in the packet is contained in the length field. The 
>    values field gives additional data or option needed for the 
>    encryption protocol. Up to now, there are only 4 encryption
>    algorithms (type 0 = OUI, type 1 = DES, type 2 = 3DES, type 3 =
>    DES modified) that could be used [5].
> 
> 3. Integrating QKD in PPP: QKD-PPP (Q3P)
> 
>    In order to exchange the encryption key, a key exchange protocol
>    is necessary. In this section, we present how to integrate QKD in 
>    PPP
> 
> 
> 3.1 ECP-QKD format
> 
>     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|    
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> 
>          Figure 2 - ECP packet carrying a QKD protocol
> 
> 
>     Type field:
>     As in the ECP standard packet the type field gives information 
>     about the option of encryption protocol negotiated. For this 
>     case, we will use an unassigned number for the QKD protocol. The 
>     selected QKD protocol is BB84 and the request to obtain an 
>     assigned number for this protocol is on going in IANA   
>     organisation [5].
> 
>     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).
> 
>     Key-length field:
>     This field indicates the length of the encryption key. It is 
>     ended on 16 bits and represents the size of the key in octet. The 
>     key size is comprised between 1 to 65535 octets. The size can be 
>     viewed as huge but we consider the possibility to use the One 
>     Time Pad function as the encryption algorithm. In this case, the
>     key size must be equal to the PPP-data size [11].
> 
> 
> Ghernaouti and Sfaxi                                         [Page 3]
> 
> INTERNET-DRAFT                                Expires: April, 29 2006
> 
>     TTL field:
>     This field can represent either the number of messages or the 
>     amount of time (in second) during which a key could be used in 
>     the encryption mechanism. When the max number of messages is 
>     reached or the deadline expires, the QKD starts.
> 
>     T field:
>     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.
> 
> 3.2 The Q3P operating mode
> 
>     We adapt PPP connection steps [RFC1661] to integrate QKD process
>     as shown Figure 3. The three first steps of Q3P are identical 
>     with PPP (phase 1 to 3). After authenticating the two nodes, the 
>     negotiation of the encryption parameters starts. In this phase, 
>     the encryption algorithm with its parameters is negotiated.
>     If the two nodes do not need to use encryption, then the network 
>     phase starts. Else, if an encryption key is required, a QKD 
phase    
>     begins. For Encryption negotiation (4) the nodes negotiate the 
>     key length and the TTL by sending an adequate ECP packet. After 
>     that (in 5), a quantum cryptography exchange starts. At the end 
>     of the quantum key distribution phase, both nodes share a secret 
>     key, the encryption algorithm and the TTL of the key. This key is
>     used in the network phase (6) while sending data. The data is 
>     enciphered thanks to the encryption key and the algorithm. When 
>     the TTL is expired, a new QKD phase starts. The end of the  
>     communication is the same as the PPP. 
>    (1)               (2)                       (3) 
> +------+        +-----------+            +--------------+
> |      | UP     |           | OPENED     |              |SUCCESS/NONE
> | Dead |------->| Establish |----------->| Authenticate |---+
> |      |        |           |            |              |   |
> +------+        +-----------+            +--------------+   |
>    ^               |                         |              |
>    |          FAIL |                    FAIL |              |
>    +<--------------+              +----------+              |
>    |                              |             (4)         |
>    |                              |       +--------------+  |
>    |                              |       |  Encryption  |<-+ 
>    |                              |       | Negotiation  |
>    |                              |       +--------------+
>    |                              |               |
>    |                              |  TLL          |  Key needed/None
>    |                              |  expires     \|/ 
>    |                              |          +---------+
>    |                              |    +---->|   QKD   |----+
>    |                              |    | (5) +---------+    |
>    |                              |    |                    |
>    |                              |    |                    |
>    |             +-----------+    |    |       +---------+  |
>    |        DOWN |           |    |    +-------|         |  |
>    +-------------| Terminate |    |            | Network |<-+
>                  |           |<---+<-----------|         |    Key
>                  +-----------+       CLOSING   +---------+ generated/
>                       (7)                          (6)       None
> 
>         Figure 3 - Proposed Q3P steps and operating mode
> 
> Ghernaouti and Sfaxi                                         [Page 4]
> 
> INTERNET-DRAFT                                Expires: April, 29 2006
> 
> 
>     The Figure 4 gives more details about Q3P operating mode. The 
>     modification are little so that the adaptation of the PPP 
>     operating mode is easy to realise.
> 
> 
>   1-	Dead state (Initial state):
>     a.  When detecting an Up event then go the Establish phase
>   2-	Establish phase:
>     a.  Configuration packets are exchanged (LCP)
>     b.  When finishing configuring the link connection go to the
>         Authentication phase
>   3-	Authentication phase:
>     a.  If required, the peer has to authenticate himself.
>     b.  If the authentication succeed or it is not required then go 
>         to Encryption negotiation phase else go to terminate phase
>   4-	Encryption Negotiation phase:
>     a.  If required, the two nodes negotiate the encryption protocol 
>         parameters and the quantum key exchange parameters (such as 
>         TTL, Key length).  If not required, go the Network phase
>     b.  After the end of the negotiation, go to QKD phase
>   5-	QKD phase:	
>     a.  The source and the detector share a secret key exchanged 
>         using quantum cryptography
>     b.  When the secret key is ready go to Network phase
>   6-	Network phase:
>     a.  The two node exchange data
>     b.  When the encryption TTL expires go to QKD phase
>     c.  If the communication is finished, go to terminate phase (a 
>         close event is generated)
>   7-	Terminate phase:
>     a.  Terminate messages are exchange, when finish go to Dead state
> 
>                      Figure 4 : The Q3P algorithm
> 
> 4. Conclusion
> 
>    For some needs, it is important to have the option to secure 
>    efficiently the data transmission between two adjacent nodes. 
>    Using quantum cryptography in conjunction with PPP offer a higher 
>    level of security. Our study points out the adaptation of 
>    the PPP protocol to integrate quantum key exchange (Q3P). The
>    modifications to PPP are identified (packet format and operating 
>    mode).
>    Applying quantum key exchange and one-time-pad function at OSI 
>    layer 2 is not only possible but will upgrade considerably, with a 
>    low cost and less effort (modification, performances,), the 
>    security level of a transmission between two adjacent nodes.
> 
> 
> 5. Security considerations
> 
>    Our proposition do not damage PPP security mechanism but enhance 
>    if by the use of quantum key echange. 
>    The unconditional security of quantum key distribution has been 
>    already proven. 
> 
> Ghernaouti and Sfaxi                                         [Page 5]
> 
> INTERNET-DRAFT                                Expires: April, 29 2006
> 
> 6. Authors Address
> 
>    Solange Ghernaouti-Helie
>    HEC, 
>    University of Lausanne
>    1015 Lausanne, Switzerland.
>    EMail: [email-masked]
> 
> 
>    Mohamed Ali Sfaxi
>    HEC, 
>    University of Lausanne
>    1015 Lausanne, Switzerland.
>    EMail: [email-masked]
> 
> 
> 
> 7  . References
> 
>    [1] Bennet, C; Brassard, G (1984). IEEE International Conference 
>        on Computers, Systems, and Signal Processing. IEEE Press, LOS 
>        ALAMITOS
> 
>    [2] Elliott, C (2002). Building the quantum network. New Journal 
>        of Physics 4 (46.1-46.12)
> 
>    [3] Elliott, C; Pearson, D; Troxel, G (2003). Quantum
>        Cryptography in Practice.
> 
>    [4] Gisin, N; Ribordy, G; Tittel, W; Zbinden, H. (2002). Quantum 
>        Cryptography. Reviews of Modern Physics 74 (2002).
>        
> 
>    [5] Ghernaouti H´elie, S; Sfaxi, M.A; Ribordy, G; Gay, O (2005). 
>        Using Quantum Key Distribution within IPSEC to secure MAN 
>        communications. MAN 2005 conference.
> 
>    [6] 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
> 
> 
>    [7] Internet Assigned Numbers Authority - IANA (2005).
>        http://www.iana.org/numbers.html
> 
>    [8] Paterson, K.G; Piper, f; Schack, R (2004). Why Quantum 
>        Cryptography?. http://eprint.iacr.org/2004/156.pdf
> 
> 
> Ghernaouti and Sfaxi                                         [Page 6]
> 
> INTERNET-DRAFT                                Expires: April, 29 2006
> 
> 
>    [9] Bradner, S., "Key words for use in RFCs to Indicate 
>        Requirement Levels", BCP 14, RFC 2119, Internet Engineering 
>        Task Force, March 1997.
> 
>    [10]Schneier, B (1996). Applied Cryptography Second Edition. New 
>        York: John Wiley & Sons, 1996
> 
>    [11]Shannon, C.E (1949). Communication theory of secrecy
>        systems. Bell System Technical Journal 28-4. 
>        
> 
> 
> Intellectual Property Statement
> 
>    The IETF takes no position regarding the validity or scope of any
>    Intellectual Property Rights or other rights that might be claimed
>    to pertain to the implementation or use of the technology 
>    described in this document or the extent to which any license 
>    under such rights might or might not be available; nor does it 
>    represent that it has made any independent effort to identify any 
>    such rights.
> 
>    Information on the procedures with respect to rights in RFC
>    documents can be found in BCP 78 and BCP 79.
> 
>    Copies of IPR disclosures made to the IETF Secretariat and any
>    assurances of licenses to be made available, or the result of an
>    attempt made to obtain a general license or permission for the use
>    of such proprietary rights by implementers or users of this
>    specification can be obtained from the IETF on-line IPR repository
>    at http://www.ietf.org/ipr.
> 
>    The IETF invites any interested party to bring to its attention 
>    any copyrights, patents or patent applications, or other 
>    proprietary rights that may cover technology that may be required 
>    to implement this standard.  Please address the information to the 
>    IETF at [email-masked].
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Ghernaouti and Sfaxi                                         [Page 7]
> 
> INTERNET-DRAFT                                Expires: April, 29 2006
> 
> 
> Full Copyright Statement
> 
>    Copyright (C) The Internet Society (2005).  This document is
>    subject to the rights, licenses and restrictions contained in BCP
>    78, and except as set forth therein, the authors retain all their
>    rights.
> 
>    This document and the information contained herein are provided on
>    an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
>    REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
>    THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
>    EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
>    THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
>    ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
>    PARTICULAR PURPOSE.
> 
> 
> Acknowledgement
> 
>    Funding for the RFC Editor function is currently provided by the
>    Internet Society.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Ghernaouti and Sfaxi                                         [Page 8]
> 
> 

_______________________________________________
Pppext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pppext

---

From: Vernon Schryver <[email-masked]>
Date: Mon, 10 Oct 2005 16:35:30 -0600 (MDT)

> Date: Mon, 10 Oct 2005 11:44:51 -0700 (PDT)
> From: "Michelle Cotton via RT" <[email-masked]>
> Cc: [email-masked]

> We will await your response.

Judging from the last time I tried to reply to you, you may wait a long
time for a response from me.  I am reluctant to leap through
Challenge-Response hoops, because Challenge-Response system are an abuse
of the network.  Either they do no good because the incoming message
was perfectly legitimate, or they generally send noise to innocent third
parties whose addresses are forged in spam.  I have seen far more
unsolicited, unprovoked substantially identical (i.e.  bulk) C-R
challenges due to forged mail than legitimate C-R challenges resulting
from mail I've sent.

> > 		  draft-ghernaouti-sfaxi-ppp-qkd-00.txt

Why isn't that draft in the familiar place on ftp.isi.edu? 
Why can't I find it at
https://datatracker.ietf.org/public/idindex.cgi?command=search_id
Is it a real (i.e. officiall published) I-D?

>     b.  When the secret key is ready go to Network phase

All standards must contain sufficiently detailed specifications to allow
people to build independent but interoperable implementations.  Those
words contain essentially no technical information.  If they represent
the design behind the proposed registry, the proposed registry must be
rejected with prejudice.

It is hard to see how ECP and quantum cryptography could interact
directly.  I can see how one might use quantum cryptography to choose
a key that could then be used with PPP-ECP, but I don't see why PPP
needs any changes.  What is the difference as far as PPP is concerned
between exchanging keys with quantum cryptography and with plain old
telephones?

Vernon Schryver    [email-masked]

---

From: James Carlson <[email-masked]>
Date: Tue, 11 Oct 2005 07:29:28 -0400

[Dropping IANA from the discussion until we have consensus; they're
plenty busy as it is.]

[Vern: please consider adding [email-masked] and [email-masked]
to your response.  Though you did post on an open list, I'm reluctant
to add addresses to the cc list without permission.  My response,
though, can be copied freely.]

> time for a response from me.  I am reluctant to leap through

Don't worry about it.  I asked IANA to forward the information along
to this list for comment.  Once there's some consensus (and I suspect
this will be quickly enough), I'll send a reply back, and I'll deal
with whatever crufty spam-elimination nonsense they're using.

> Is it a real (i.e. officiall published) I-D?

I believe we're looking at the only copy of it.

> >     b.  When the secret key is ready go to Network phase

Well, that's not quite true.  There's also the completely baffling
ECP-QKD key option.  If you're using some external mechanism to
exchange keys, I don't see how or why you need to pass the key along
as a configuration option.  That makes no sense.  It clearly destroys
whatever goodness you might have hoped to get from the original key
exchange, because you've just revealed the shared secret.

Worse still, it specifies a key with no algorithm!  How on Earth can a
key be used without some agreed algorithm?

And even more mysterious: of what possible use is a "one time pad?"
This implies that you could send up to 64KB worth of payload on the
link.  Period.  That's a pittance of data.  How is it ever useful?

> between exchanging keys with quantum cryptography and with plain old

Exactly.  That's what I said at the start: since it clearly requires
careful installation of special-purpose hardware dedicated between the
two peers, I don't see why it can't be settled by mutual consent,
rather than requiring negotiation.

Anyway, I agree that the submitter hasn't even approached the burden
of disclosing what the new option might do, and thus we can't say it
has received any sort of review.

Any disagreement amongst those reading?

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