NTP Security Protocol

Transcription

1 NTP Security Prtcl David L. Mills University f Delaware mailt:mills@udel.edu Sir Jhn Tenniel; Alice s Adventures in Wnderland,Lewis Carrll 31-Oct-05 1

2 Security prtcl requirements It must interperate with the existing NTP architecture mdel and prtcl design. In particular, it must supprt the symmetric key scheme described in RFC It must prvide fr the independent cllectin f cryptgraphic values and time values. A NTP packet is accepted fr prcessing nly when the required cryptgraphic values have been btained and verified and the NTP header has passed all sanity checks. It must nt significantly degrade the ptential accuracy f the NTP synchrnizatin algrithms. In particular, it must nt make unreasnable demands n the netwrk r hst prcessr and memry resurces. It must be resistant t cryptgraphic attacks, specifically thse identified in the security mdel abve. In particular, it must be tlerant f peratinal r implementatin variances, such as packet lss r misrder, r subptimal cnfiguratins. 31-Oct-05 2

3 Security prtcl requirements (cntinued) It must build n a widely available suite f cryptgraphic algrithms, yet be independent f the particular chice. In particular, it must nt require data encryptin ther than incidental t signature and ckie encryptin peratins. It must functin in all the mdes supprted by NTP, including client/server, symmetric and bradcast mdes. It must nt require intricate per-client r per-server cnfiguratin ther than the availability f the required cryptgraphic keys and certificates. The reference implementatin must cntain prvisins t generate cryptgraphic key files specific t each client and server. 31-Oct-05 3

4 Autkey security prtcl NTP and Autkey prtcls wrk independently fr each client, with tentative utcmes cnfirmed nly after bth succeed. Public keys and certificates are btained and verified relatively infrequently using X.509 certificates and certificate trails. Sessin keys are derived frm public keys using fast algrithms. Each NTP message is individually authenticated using sessin key and message digest (keyed MD5). A prventic trail is a sequence f NTP servers each synchrnized and cryptgraphically verified t the next lwer stratum server and ending n ne r mre trusted servers. Prventic trails are cnstructed frm each server t the trusted hsts at decreasing stratum levels. When server time and at least ne prventic trail are verified, the hst is admitted t the ppulatin used t synchrnize the system clck. 31-Oct-05 4

5 Sessin keys Surce Address Dest Address Key ID Ckie Hash NTPv4 Sessin Key NTPv4 sessin keys have fur 32-bit wrds (16 ctets ttal). The sessin key value is the 16-ctet MD5 message digest f the sessin key. Key IDs have pseud-randm values and are used nly nce. A special key ID value f zer is used as a crypt-nak reply. In bradcast mdes and in any message including an extensin field, the ckie has a public value (zer). These messages are always signed. In client/server mdes the ckie is a hash f the addresses and a private value. In symmetric mdes the ckie is a randm rll; in case bth peers generate ckies, the agreed ckie is the EXOR f the tw values. 31-Oct-05 5

6 Cmputing the ckie Client Address Server Address Key ID (0) Private Value Ckie Cmpute Hash Cmpute Signature Ckie Signature and Timestamp The server generates a ckie unique t the client and server addresses and its wn private value. It returns the ckie, signature and timestamp t the client in an extensin field. The ckie is transmitted frm server t client encrypted by the clien public key. The server uses the ckie t validate requests and cnstruct replies. The client uses the ckie t validate the reply and checks that the request key ID matches the reply key ID. 31-Oct-05 6

7 Generating the sessin key list Surce Address Dest Address Ckie Key ID Final Index Final Key ID Next Key ID Index n + 1 Cmpute Hash Index n Sessin Key ID List Cmpute Signature Signature The server rlls a randm 32-bit seed as the initial key ID and selects the ckie. Messages with a zer ckie cntain nly public values. The initial sessin key is cnstructed using the given addresses, ckie and initial key ID. The sessin key value is stred in the key cache. The next sessin key is cnstructed using the first fur ctets f the sessin key value as the new key ID. The server cntinues t generate the full list. The final index number and last key ID are prvided in an extensin field with signature and timestamp. 31-Oct-05 7

8 Sending messages NTP Header and Extensin Fields Cmpute Hash Key ID Sessin Key ID List Message Authenticatr Cde (MAC) The message authenticatr cde (MAC) cnsists f the MD5 message digest f the NTP header and extensin fields using the sessin key ID and value stred in the key cache. The server uses the sessin key ID list in reverse rder and discards each key value after use. An extensin field cntaining the last index number and key ID is included in the first packet transmitted (last n the list). This extensin field can be prvided upn request at any time. When all entries in the key list are used, a new ne is generated. 31-Oct-05 8

9 Receiving messages NTP Header and Extensin Fields Message Authenticatr Cde (MAC) Cmpute Hash Key ID Message Digest Message Digest Cmpare The intent is nt t hide the message cntents, just verify where it came frm and that it has nt been mdified in transit. The MAC message digest is cmpared with the cmputed digest f the NTP header and extensin fields using the sessin key ID in the MAC and the key value cmputed frm the addresses, key ID and ckie. If the ckie is zer, the message cntains public values. Anybdy can validate the message r make a valid message cntaining any values. If the ckie has been determined by secret means, nbdy except the parties t the secret can validate a message r make a valid message. 31-Oct-05 9

10 NTP prtcl header and timestamp frmats Cryptsum NTP Prtcl Header Frmat (32 bits) LI VN Mde Strat Pll Rt Delay Rt Dispersin Reference Identifier Reference Timestamp (64) Originate Timestamp (64) Receive Timestamp (64) Prec LI leap warning indicatr VN versin number (4) Strat stratum (0-15) Pll pll interval (lg2) Prec precisin (lg2) NTP Timestamp Frmat (64 bits) Secnds (32) Fractin (32) Value is in secnds and fractin since 0 h 1 January 1900 Authenticatr (Optinal) Transmit Timestamp (64) Extensin Field 1 (ptinal) Extensin Field 2 (ptinal) Key/Algrithm Identifier Message Digest (128) NTP v4 Extensin Field Field Type Length Extensin Field (padded t 32-bit bundary) Last field padded t 64-bit bundary NTP v3 and v4 NTP v4 nly authenticatin nly Authenticatr uses MD5 cryptsum f NTP header plus extensin fields (NTPv4) 31-Oct-05 10

11 NTPv4 extensin fields Field Type Length Assciatin ID Timestamp Filestamp Value Length Value Signature Length Signature Padding (as needed) Value Fields (ptinal) NTP Extensin Field New extensin fields frmat defined fr NTP Versin 4 Fields are prcessed in rder. Requests may be transmitted with r withut value fields. Last field padded t 64-bit bundary; all thers padded t 32-bit bundary. Field length cvers all paylad and padding. 31-Oct-05 11

12 Hst status wrd Digest/Signature NID Client Ident Hst Hst status wrd is cnstructed at initializatin time. Client and server exchange status wrds with ffered identity schemes Bth client and server agree n the same scheme Digest/Signature NID 16 bits fr Netwrk ID f the message digest/signature encryptin scheme Client 8 bits available fr client Autkey prtcl peratins Hst 8 bits available fr hst Autkey peratins and ffered identity scheme 31-Oct-05 12

13 Autkey prtcl exchanges Parameter Exchange (ASSOC message - nt signed) Exchange hst names; agree n digest/signature and identity schemes. Optinal: verify hst name/address using reverse-dns. Certificate Exchange (CERT message) Obtain and verify certificates n the trail t a trusted rt certificate. Identity Exchange (IFF, GQ and MV messages) Verify server identity using agreed identity scheme (TC, IFF, GQ, MV). Values Exchange (COOKIE and AUTO messages) Obtain and verify the ckie, autkey values and leapsecnds table, depending n the assciatin mde (client-server, bradcast, symmetric). Signature Exchange (SIGN message) Request the server t sign and return a client certificate. The exchange is valid nly when the client has synchrnized t a prventic surce and the server identity has been cnfirmed. 31-Oct-05 13

14 Parameter and certificate exchanges Client Server Send hst name and status wrd (unsigned) Agree digest NID and ID scheme Assc Request Assc Respnse Certificate Request Agree digest NID And ID scheme Send hst name and status wrd (unsigned) Verify signature and certificate Certificate Respnse Send X.509 certificate and signature Initial exchange f hst status wrds defines server message digest and signature encryptin algrithm and identity scheme. The Certificate Request/Respnse cycle repeats as needed. Primary (stratum 1) certificate is explicitly trusted and self-signed. Secndary certificates are signed by the next lwer stratum server and validated with its public key. 31-Oct-05 14

15 Identificatin exchange Client Server Cmpute nnce1 and send Verify respnse and signature Challenge Request Challenge Respnse Cmpute nnce2 and respnse Send respnse and signature This is a challenge-respnse scheme Client Alice and server Bb share a cmmn set f parameters and a private grup key b. Alice rlls randm nnce r and sends t Bb. Bb rlls randm nnce k, cmputes a ne-way functin f(r, k, b) and sends t Alice. Alice cmputes sme functin g(f, b) t verify that Bb knws b. The signature prevents message mdificatin and binds the respnse t Bb s private key. An interceptr can see the challenge and respnse, but cannt determine k r b r hw t cnstruct a respnse acceptable t Alice. 31-Oct-05 15

16 Ckie exchange Client Active Peer Server Passive Peer Send public key and signature Verify signature; decrypt ckie Ckie Request Ckie Respnse Verify signature; encrypt ckie Send encrypted ckie and signature Client sends public key t server withut signature when nt synchrnized. Symmetric active peer sends public key and signature t passive peer when synchrnized. Server ckie is encrypted frm the hash f surce/destinatin addresses, zer key ID and server private value. Symmetric passive ckie is a randm value fr every exchange. Server private value is refreshed and prtcl restarted nce per day. 31-Oct-05 16

17 Autkey exchange Client Active Peer Server Passive Peer Send request and signature Verify signature; install values Autkey Request Autkey Respnse Verify signature Send autkey values and signature Server generates key list and signature calculated t last abut ne hur. Client sends request t server withut signature when nt synchrnized. Server replies with the last index number and key ID n the list. Bradcast server uses AUTO respnse fr the first message after regenerating the key and ASSOC respnse fr all ther messages. 31-Oct-05 17

18 Sign certificate exchange Client Active Peer Server Passive Peer Send certificate and signature Verify signature; install certificate; Sign Request Sign Respnse Verify signature; sign certificate Send certificate and signature. This is used t authenticate client t server, with server acting as de fact certificate authrity using encrypted credential scheme TBD. Client sends certificate t server with r withut signature. Server extracts request data and signs with server private key. Client verifies certificate and signature. Subsequently, client supplies this certificate rather than self-signed certificate, s clients can verify with server public key. 31-Oct-05 18

19 Bradcast/multicast mde The bradcast server sends messages at fixed intervals. The first message sent after regenerating the key list includes the autkey values and signature. Other messages include the server assciatin ID, but n signature. This is used as a handle fr clients t request the autkey values if necessary. These messages are cnsidered public values, s the ckie value is zer. When a multicast client receives the first message, it temprarily switches t client/server mde in rder t calibrate the netwrk prpagatin delay and authenticate the server. The client first btains the parameters and verifies the certificate, identity and signature as in client/server mde, then btains the autkey values and signature. When the prpagatin delay is calibrated, the client switches back t bradcast client mde and makes n further transmissins. 31-Oct-05 19

20 Bradcast/multicast mde prtcl Server Client Regular peratin Assc Respnse Request Respnse Mbilize assciatin generate key list switch t client/server Verify certificate, identity and signature Send autkey and signature Regular peratin Autkey Request Autkey Respnse Assc Respnse Request autkey values Verify signature calibrate delay switch t multicast client 31-Oct-05 20

21 Symmetric mdes Symmetric peers can each synchrnize the ther, depending n which ne has the lwest synchrnizatin distance. One f the peers must be active; the ther can be active r passive. Each peer cmputes a ckie and generates key lists independently. The passive peer is presumably already synchrnized t a prventic surce. It mbilizes an assciatin upn arrival f the first message frm the active peer and begins a parameter exchange. The active peer prceeds thrugh the varius exchanges until synchrnized t the passive peer. The passive peer cntinues the parameter exchange. When the active peer is synchrnized, the passive peer prceeds thrugh the varius exchanges until synchrnized t the active peer. When the passive peer is synchrnized, bth peers cntinue using the key lists as necessary. An AUTO respnse with 31-Oct-05 21

22 Symmetric mdes prtcl Obtain credentials; mbilize assciatin; generate key list. Symmetric Active Ckie Request Ckie Respnse Autkey Request Symmetric Passive Obtain credentials; mbilize assciatin; cmpute ckie. Generate key list; send ckie; send autkey values. Regenerate key list; send autkey values. Autkey Respnse 31-Oct-05 22

23 TAI leapsecnd table The UTC leapsecnd table cntains the histric epches, in NTP secnds, f leapsecnd insertins since UTC began in 1972 An authritative cpy is n NIST NTP servers in pub/leap-secnds It can be retrieved directly frm NIST using FTP It can be retrieved frm a server r peer during the Autkey dance If bth peers have the table, nly the mst recent is used NTP prvides the secnds ffset relative t TAI t the kernel Applicatin prgram interface The ntp_gettime() system call returns the current time and secnds ffset relative t TAI Currently, nly FreeBSD, Linux and lcally mdified SunOS and Tru64 (Alpha) have mdified kernels t supprt this interface 31-Oct-05 23

24 Further infrmatin Netwrk Time Prtcl (NTP): Current NTP Versin 3 and 4 sftware and dcumentatin FAQ and links t ther surces and interesting places David L. Mills: Papers, reprts and memranda in PstScript and PDF frmats Briefings in HTML, PstScript, PwerPint and PDF frmats Cllabratin resurces hardware, sftware and dcumentatin Sngs, pht galleries and after-dinner speech scripts FTP server ftp.udel.edu (pub/ntp directry) Current NTP Versin 3 and 4 sftware and dcumentatin repsitry Cllabratin resurces repsitry Related prject descriptins and briefings See Current Research Prject Descriptins and Briefings at 31-Oct-05 24