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

From: "Michelle Cotton via RT" <[email-masked]>
Date: Fri, 4 Nov 2005 09:40:55 -0800 (PST)

PPPEXT Working Group:

We are resending this message as we have not yet seen a response.

Thank you for your assistance.

Michelle Cotton
IANA

> [michelle.cotton - Mon Oct 10 11:44:50 2005]:
> 
> 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: James Carlson <[email-masked]>
Date: Fri, 4 Nov 2005 13:38:34 -0500

> We are resending this message as we have not yet seen a response.

We've been discussing the issues with the draft authors.

The current group consensus (taken on Monday, October 31st) is that
the draft as presented does not provide sufficient justification for
allocating a code point for this purpose.

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