Digital Imaging and Cmmunicatins in Medicine (DICOM) Supplement 204 TLS Security Prfiles Prepared by: DICOM Standards Cmmittee, Wrking Grup 6 1300 N. 17th Street Rsslyn, Virginia 22209 USA VERSION: Public Cmment Draft 9 September, 2017 This is a draft dcument. D nt circulate, qute, r reprduce it except with the apprval f NEMA. Develped pursuant t DICOM Wrk Item 2017-04-D
Template fr DICOM Page i 1 2 3 4 5 6 Table f Cntents Scpe and Field f Applicatin... i Changes t NEMA Standards Publicatin PS 3.15-2017d... i B.Y THE BEST CURRENT PRACTICE TLS SECURE CONNECTION PROFILE... 2 B.X THE BEST CURRENT PRACTICES PLUS RESTRICTIONS TLS SECURE TRANSPORT CONNECTION PROFILE... 3 7 Scpe and Field f Applicatin 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 Tw new Secure Cnnectin prfiles are added t make DICOM cnsistent with the latest RFCs and best practices fr TLS security. These are: 1. A Best Practices TLS Prfile that requires cmpliance with the IETF BCP 195 Recmmendatins fr Secure Use f Transprt Layer Security (TLS) and Datagram Transprt Layer Security (DTLS). This prfile requires that TLS negtiatin start with the strng security prtectin parameters, and allws prgressive negtiatin f weaker prtectin dwn t a minimum prtectin limit. 2. A Nn-Dwngrading Best Practices TLS Prfile that des nt permit negtiatin f weaker prtectins. This prfile will refuse a cnnectin that is nt the initial strng level f prtectin. The ld Basic TLS Secure Transprt Cnnectin Prfile is retired. IETF cnsiders it inadequate security, because the methds fr breaking in are well knwn. Implementatins that use it will nt interperate with the Best Practices TLS Prfile. The ld AES TLS Secure Transprt Cnnectin Prfile is retired. Implementatins that use it will nt interperate with the Nn-Dwngrading Best Practices TLS Prfile. Implementatins that use it will interperate with the Best Practices TLS Prfile because it is acceptable as ne f the lwer levels f prtectin that can be negtiated. 24 Changes t NEMA Standards Publicatin PS 3.15-2017d 25 Digital Imaging and Cmmunicatins in Medicine 26 Mdify Sectin 2, Nrmative References 28 RFC3853 S/MIME Advanced Encryptin Standard (AES) Requirement fr the Sessin Initiatin Prtcl (SIP) RFC5246 Transprt Layer Security (TLS) 1.2
Template fr DICOM Page 2 30 [RFC7525] IETF. May 2015. Recmmendatins fr Secure Use f Transprt Layer Security (TLS) and Datagram Transprt Layer Security (DTLS). http://tls.ietf.rg/html/rfc7525. 32 [BCP195] IETF. May 2015. Recmmendatins fr Secure Use f Transprt Layer Security (TLS) and Datagram Transprt Layer Security (DTLS). http://tls.ietf.rg/html/bcp195. 34 RFC5424 The Syslg Prtcl 36 Replace Annex B.1 as shwn B.1 The Basic TLS Secure Transprt Cnnectin Prfile 38 Retired, see PS 3.15, 2017x Replace Annex B.3 as shwn 40 B.3 The AES TLS Secure Transprt Cnnectin Prfile Retired, see PS 3.15, 2017x 42 Nte: applicatins implementing the AES TLS Secure Transprt Cnnectin Prfile will cnnect and interperate with implementatins f the Best Practices TLS Prfile, see B.y. 44 Add Annex B.y, Best Practices TLS Prfile 46 B.Y THE BEST PRACTICES TLS PROFILE 48 50 52 54 56 58 60 62 An implementatin that supprts the Best Practices TLS Prfile shall utilize the framewrk and negtiatin mechanism specified by the Transprt Layer Security prtcl. It shall cmply with the BCP195 best current practices frm the IETF. Nte: 1. BCP195 is currently als published as RFC7525 Recmmendatins fr Secure Use f Transprt Layer Security (TLS). Bth prvide suggestins fr prper use f TLS 1.2 and allw apprpriate fallback rules. 2. Existing implementatins that are cmpliant with the DICOM AES TLS Secure Cnnectin Prfile are able t interperate with this prfile. This prfile adds significant recmmendatins by the IETF, but des nt make them mandatry. This is the IETF best current practice fr upgrading an installed base. IP prts n which an implementatin accepts TLS cnnectins, r the mechanism by which these prt numbers are selected r cnfigured, shall be stated in the Cnfrmance Statement. These prts shall be different frm prts used fr ther types f transprt cnnectins (secure r unsecure). Nte: It is strngly recmmended that systems supprting the Best Practices TLS Prfile use the registered prt number "2762 dicm-tls" fr the DICOM Upper Layer Prtcl n TLS: (decimal). The Cnfrmance Statement shall indicate what mechanisms the implementatin supprts fr Key Management.
Template fr DICOM Page 3 64 66 68 The prfile des nt specify a key management infrastructure. The cnfrmance statements fr the AE's dcument hw each AE can perfrm key management, e.g., certificate prvisining. If there is a cmmn key management slutin, then this prfile assures that cnnectins can be established. When an integrity check fails, the cnnectin shall be drpped per the TLS prtcl, causing bth the sender and the receiver t issue an A-P-ABORT indicatin t the upper layers with an implementatinspecific prvider reasn. The prvider reasn used shall be dcumented in the Cnfrmance Statement. 70 Add Annex B.x 72 74 76 B.X THE NON-DOWNGRADING BEST PRACTICES TLS PROFILE An implementatin that supprts the Nn-Dwngrading Best Practices TLS Prfile shall utilize the framewrk and negtiatin mechanism specified by the Transprt Layer Security prtcl. It shall cmply with the BCP195 best current practices frm the IETF with the additinal restrictins enumerated belw. The fllwing additins are made t BCP195 requirements. They change sme f the "shuld" recmmendatins in the RFC int requirements. 78 80 82 84 86 88 90 92 Implementatins shall nt negtiate TLS versin 1.1 [RFC4346] r TLS versin 1.0 [RFC2246] Implementatins shall nt negtiate DTLS versin 1.0 [RFC4347] In cases where an applicatin prtcl allws implementatins r deplyments a chice between strict TLS cnfiguratin and dynamic upgrade frm unencrypted t TLS-prtected traffic (such as STARTTLS), clients and servers SHALL prefer strict TLS cnfiguratin. Applicatin prtcls typically prvide a way fr the server t ffer TLS during an initial prtcl exchange, and smetimes als prvide a way fr the server t advertise supprt fr TLS (e.g., thrugh a flag indicating that TLS is required); unfrtunately, these indicatins are sent befre the cmmunicatin channel is encrypted. A client SHALL attempt t negtiate TLS even if these indicatins are nt cmmunicated by the server. the fllwing cipher suites SHALL be supprted: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 94 96 98 100 IP prts n which an implementatin accepts TLS cnnectins, r the mechanism by which these prt numbers are selected r cnfigured, shall be stated in the Cnfrmance Statement. These prts shall be different frm prts used fr ther types f transprt cnnectins (secure r unsecure). Nte: It is strngly recmmended that systems supprting the Best Practices TLS Prfile use the registered prt number "2762 dicm-tls" fr the DICOM Upper Layer Prtcl n TLS: (decimal). The Cnfrmance Statement shall als indicate what mechanisms the implementatin supprts fr Key Management.
Template fr DICOM Page 4 102 104 106 108 110 112 IP prts n which an implementatin accepts TLS cnnectins, r the mechanism by which these prt numbers are selected r cnfigured, shall be stated in the Cnfrmance Statement. These prts shall be different frm prts used fr ther types f transprt cnnectins (secure r unsecure). Nte: It is strngly recmmended that systems supprting the Best Practices TLS Prfile use the registered prt number "2762 dicm-tls" fr the DICOM Upper Layer Prtcl n TLS: (decimal). The Cnfrmance Statement shall indicate what mechanisms the implementatin supprts fr Key Management. The prfile des nt specify a key management infrastructure. The cnfrmance statements fr the AE's dcument hw each AE can perfrm key management, e.g., certificate prvisining. If there is a cmmn key management slutin, then this prfile assures that cnnectins can be established. When an integrity check fails, the cnnectin shall be drpped per the TLS prtcl, causing bth the sender and the receiver t issue an A-P-ABORT indicatin t the upper layers with an implementatinspecific prvider reasn. The prvider reasn used shall be dcumented in the Cnfrmance Statement. 114