RFC 3711 - The Secure Real-time Transport Protocol (SRTP)(6)

时间:2006-10-28 来源: 作者: 点击:
SP2000,pp.56-73,2000. [RFC1750]Eastlake,D.,Crocker,S.andJ.Schiller,"Randomness RecommendationsforSecurity",RFC1750,December1994. [RFC2675]Borman,D.,Deering,S.andR.Hinden,"IPv6Jumbograms", RFC2675,Aug
  
             S&P2000, pp. 56-73, 2000.

   [RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
             Recommendations for Security", RFC 1750, December 1994.

   [RFC2675] Borman, D., Deering, S. and R. Hinden, "IPv6 Jumbograms",
             RFC 2675, August 1999.

   [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukuhsima, H.,
             Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K.,
             Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke,
             T., Yoshimura, T. and H. Zheng, "RObust Header Compression:
             Framework and Four Profiles: RTP, UDP, ESP, and
             uncompressed (ROHC)", RFC 3095, July 2001.

   [RFC3242] Jonsson, L-E. and G. Pelletier, "RObust Header Compression
             (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP ", RFC
             3242, April 2002.

   [SDMS]    Andreasen, F., Baugher, M. and D. Wing, "Session
             Description Protocol Security Descriptions for Media
             Streams", Work in Progress.

   [SWO]     Svanbro, K., Wiorek, J. and B. Olin, "Voice-over-IP-over-
             wireless", Proc.  PIMRC 2000, London, Sept. 2000.

   [V02]     Vaudenay, S., "Security Flaws Induced by CBC Padding -
             Application to SSL, IPsec, WTLS...", Advances in
             Cryptology, EUROCRYPT’02, LNCS 2332, pp. 534-545.

   [WC81]    Wegman, M. N., and  J.L. Carter, "New Hash Functions and
             Their Use in Authentication and Set Equality", JCSS 22,
             265-279, 1981.

Appendix A: Pseudocode for Index Determination

   The following is an example of pseudo-code for the algorithm to
   determine the index i of an SRTP packet with sequence number SEQ.  In
   the following, signed arithmetic is assumed.

         if (s_l < 32,768)
            if (SEQ - s_l > 32,768)
               set v to (ROC-1) mod 2^32
            else
               set v to ROC
            endif
         else
            if (s_l - 32,768 > SEQ)
               set v to (ROC+1) mod 2^32
            else
               set v to ROC
            endif
         endif
         return SEQ + v*65,536

Appendix B: Test Vectors

   All values are in hexadecimal.

B.1.  AES-f8 Test Vectors

   SRTP PREFIX LENGTH  :   0

   RTP packet header   :   806e5cba50681de55c621599

   RTP packet payload  :   70736575646f72616e646f6d6e657373
                           20697320746865206e65787420626573
                           74207468696e67

   ROC                 :   d462564a
   key                 :   234829008467be186c3de14aae72d62c
   salt key            :   32f2870d
   key-mask (m)        :   32f2870d555555555555555555555555
   key XOR key-mask    :   11baae0dd132eb4d3968b41ffb278379

   IV                  :   006e5cba50681de55c621599d462564a
   IV’                 :   595b699bbd3bc0df26062093c1ad8f73

   j = 0
   IV’ xor j           :   595b699bbd3bc0df26062093c1ad8f73
   S(-1)               :   00000000000000000000000000000000
   IV’ xor S(-1) xor j :   595b699bbd3bc0df26062093c1ad8f73
   S(0)                :   71ef82d70a172660240709c7fbb19d8e
   plaintext           :   70736575646f72616e646f6d6e657373
   ciphertext          :   019ce7a26e7854014a6366aa95d4eefd

   j = 1
   IV’ xor j           :   595b699bbd3bc0df26062093c1ad8f72
   S(0)                :   71ef82d70a172660240709c7fbb19d8e
   IV’ xor S(0) xor j  :   28b4eb4cb72ce6bf020129543a1c12fc
   S(1)                :   3abd640a60919fd43bd289a09649b5fc
   plaintext           :   20697320746865206e65787420626573
   ciphertext          :   1ad4172a14f9faf455b7f1d4b62bd08f

   j = 2
   IV’ xor j           :   595b699bbd3bc0df26062093c1ad8f71
   S(1)                :   3abd640a60919fd43bd289a09649b5fc
   IV’ xor S(1) xor j  :   63e60d91ddaa5f0b1dd4a93357e43a8d
   S(2)                :   220c7a8715266565b09ecc8a2a62b11b
   plaintext           :   74207468696e67
   ciphertext          :   562c0eef7c4802

B.2.  AES-CM Test Vectors

    Keystream segment length: 1044512 octets (65282 AES blocks)
    Session Key:      2B7E151628AED2A6ABF7158809CF4F3C
    Rollover Counter: 00000000
    Sequence Number:  0000
    SSRC:             00000000
    Session Salt:     F0F1F2F3F4F5F6F7F8F9FAFBFCFD0000 (already shifted)
    Offset:           F0F1F2F3F4F5F6F7F8F9FAFBFCFD0000

    Counter                            Keystream

    F0F1F2F3F4F5F6F7F8F9FAFBFCFD0000   E03EAD0935C95E80E166B16DD92B4EB4
    F0F1F2F3F4F5F6F7F8F9FAFBFCFD0001   D23513162B02D0F72A43A2FE4A5F97AB
    F0F1F2F3F4F5F6F7F8F9FAFBFCFD0002   41E95B3BB0A2E8DD477901E4FCA894C0
    ...                                ...
    F0F1F2F3F4F5F6F7F8F9FAFBFCFDFEFF   EC8CDF7398607CB0F2D21675EA9EA1E4
    F0F1F2F3F4F5F6F7F8F9FAFBFCFDFF00   362B7C3C6773516318A077D7FC5073AE
    F0F1F2F3F4F5F6F7F8F9FAFBFCFDFF01   6A2CC3787889374FBEB4C81B17BA6C44

   Nota Bene: this test case is contrived so that the latter part of the
   keystream segment coincides with the test case in Section F.5.1 of
   [CTR].

B.3.  Key Derivation Test Vectors

   This section provides test data for the default key derivation
   function, which uses AES-128 in Counter Mode.  In the following, we
   walk through the initial key derivation for the AES-128 Counter Mode
   cipher, which requires a 16 octet session encryption key and a 14
   octet session salt, and an authentication function which requires a
   94-octet session authentication key.  These values are called the
   cipher key, the cipher salt, and the auth key in the following.
   Since this is the initial key derivation and the key derivation rate
   is equal to zero, the value of (index DIV key_derivation_rate) is
   zero (actually, a six-octet string of zeros).  In the following, we
   shorten key_derivation_rate to kdr.

   The inputs to the key derivation function are the 16 octet master key
   and the 14 octet master salt:

      master key:  E1F97A0D3E018BE0D64FA32C06DE4139
      master salt: 0EC675AD498AFEEBB6960B3AABE6

   We first show how the cipher key is generated.  The input block for
   AES-CM is generated by exclusive-oring the master salt with the
   concatenation of the encryption key label 0x00 with (index DIV kdr),
   then padding on the right with two null octets (which implements the
   multiply-by-2^16 operation, see Section 4.3.3).  The resulting value
   is then AES-CM- encrypted using the master key to get the cipher key.

      index DIV kdr:                 000000000000
      label:                       00
      master salt:   0EC675AD498AFEEBB6960B3AABE6
      -----------------------------------------------
      xor:           0EC675AD498AFEEBB6960B3AABE6     (x, PRF input)

      x*2^16:        0EC675AD498AFEEBB6960B3AABE60000 (AES-CM input)

      cipher key:    C61E7A93744F39EE10734AFE3FF7A087 (AES-CM output)

   Next, we show how the cipher salt is generated.  The input block for
   AES-CM is generated by exclusive-oring the master salt with the
   concatenation of the encryption salt label.  That value is padded and
   encrypted as above.

      index DIV kdr:                 000000000000
      label:                       02
      master salt:   0EC675AD498AFEEBB6960B3AABE6

      ----------------------------------------------
      xor:           0EC675AD498AFEE9B6960B3AABE6     (x, PRF input)

      x*2^16:        0EC675AD498AFEE9B6960B3AABE60000 (AES-CM input)

                     30CBBC08863D8C85D49DB34A9AE17AC6 (AES-CM ouptut)

      cipher salt:   30CBBC08863D8C85D49DB34A9AE1

   We now show how the auth key is generated.  The input block for AES-
   CM is generated as above, but using the authentication key label.

      index DIV kdr:                   000000000000
      label:                         01
      master salt:     0EC675AD498AFEEBB6960B3AABE6
      -----------------------------------------------
      xor:             0EC675AD498AFEEAB6960B3AABE6     (x, PRF input)

      x*2^16:          0EC675AD498AFEEAB6960B3AABE60000 (AES-CM input)

   Below, the auth key is shown on the left, while the corresponding AES
   input blocks are shown on the right.

   auth key                           AES input blocks
   CEBE321F6FF7716B6FD4AB49AF256A15   0EC675AD498AFEEAB6960B3AABE60000
   6D38BAA48F0A0ACF3C34E2359E6CDBCE   0EC675AD498AFEEAB6960B3AABE60001
   E049646C43D9327AD175578EF7227098   0EC675AD498AFEEAB6960B3AABE60002
   6371C10C9A369AC2F94A8C5FBCDDDC25   0EC675AD498AFEEAB6960B3AABE60003
   6D6E919A48B610EF17C2041E47403576   0EC675AD498AFEEAB6960B3AABE60004
   6B68642C59BBFC2F34DB60DBDFB2       0EC675AD498AFEEAB6960B3AABE60005

Authors’ Addresses

   Questions and comments should be directed to the authors and
   avt@ietf.org:

   Mark Baugher
   Cisco Systems, Inc.
   5510 SW Orchid Street
   Portland, OR 97219 USA

   Phone:  +1 408-853-4418
   EMail:  mbaugher@cisco.com

   Elisabetta Carrara
   Ericsson Research
   SE-16480 Stockholm
   Sweden

   Phone:  +46 8 50877040
   EMail:  elisabetta.carrara@ericsson.com

   David A. McGrew
   Cisco Systems, Inc.
   San Jose, CA 95134-1706
   USA

   Phone:  +1 301-349-5815
   EMail:  mcgrew@cisco.com

   Mats Naslund
   Ericsson Research
   SE-16480 Stockholm
   Sweden

   Phone:  +46 8 58533739
   EMail:  mats.naslund@ericsson.com

   Karl Norrman
   Ericsson Research
   SE-16480 Stockholm
   Sweden

   Phone:  +46 8 4044502
   EMail:  karl.norrman@ericsson.com

Full Copyright Statement

   Copyright (C) The Internet Society (2004).  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.

Intellectual Property

   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 ietf-
   ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.
------分隔线----------------------------
顶一下
(3)
100%
踩一下
(0)
0%
------分隔线----------------------------
最新评论 查看所有评论
发表评论 查看所有评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
用户名: 密码: 验证码:
推荐内容