Docs Italia beta

Documenti pubblici, digitali.

4.1. Sicurezza di canale e/o identificazione delle organizzazioni

4.1.1. [IDAC01] Direct Trust Transport-Level Security

4.1.1.1. Scenario

Comunicazione tra fruitore ed erogatore che assicuri, a livello di canale:

  • confidenzialità
  • integrità
  • identificazione dell’erogatore, quale organizzazione
  • difesa dalle minacce derivanti dagli attacchi: Replay Attack e Spoofing

4.1.1.2. Descrizione

Il presente profilo assume l’esistenza di un trust tra fruitore (client) ed erogatore (server), che permette il riconoscimento del certificato X.509, o la CA emittente dell’erogatore, così come previsto dal protocollo Transport Layer Security [5] [6].

La sequenza dei messaggi di richiesta/risposta avviene dopo aver instaurato il canale di trasmissione sicuro.

4.1.1.3. Dettaglio

sequenceDiagram participant F as Fruitore participant E as Erogatore activate F F->>E: 1. Request() activate E E-->>F: 2. Reply() deactivate E deactivate F

Fig. 4.2 Sicurezza di canale e/o Autenticazione dell’Erogatore

4.1.1.3.1. Regole di processamento

Il canale sicuro tra erogatore e fruitore viene instaurato utilizzando il protocollo TLS, secondo le modalità specificate alla sezione Elenco degli algoritmi.

A: Richiesta

  1. Il fruitore costruisce un messaggio di richiesta.
  2. Il fruitore spedisce sul canale sicuro stabilito il messaggio di richiesta all’interfaccia di servizio dell’erogatore.

B: Risposta

  1. L’erogatore elabora il messaggio e restituisce il risultato.

Come indicato in RFC 5246 l’impiego del protocollo TLS garantisce a livello di canale:

  • l’autenticazione dell’erogatore identificato mediante il certificato X.509
  • la confidenzialità dei dati scambiati
  • l’integrità dei dati scambiati

L’impiego del protocollo TLS 1.2 o maggiore, mitiga il rischio di:

  • Replay Attack
  • Spoofing

4.1.2. [IDAC02] Direct Trust mutual Transport-Level Security

4.1.2.1. Scenario

Comunicazione tra fruitore ed erogatore che assicuri a livello di canale:

  • confidenzialità
  • integrità
  • identificazione dell’erogatore e del fruitore, quale organizzazioni
  • difesa dalle minacce derivanti dagli attacchi: Replay Attack e Spoofing

4.1.2.2. Descrizione

Il presente profilo assume l’esistenza di un trust tra fruitore (client) ed erogatore (server), che permette il riconoscimento da entrambe le parti dei certificati X.509, o le CA emittenti, così come previsto dal protocollo Transport Layer Security [5] [6].

La sequenza dei messaggi di richiesta/risposta avviene dopo aver instaurato il canale di trasmissione sicuro.

4.1.2.3. Dettaglio

sequenceDiagram participant F as Fruitore participant E as Erogatore activate F F->>E: 1. Request() activate E E-->>F: 2. Reply() deactivate E deactivate F

Fig. 4.3 Sicurezza di canale e/o Autenticazione delle organizzazioni

4.1.2.3.1. Regole di processamento

Il canale sicuro tra erogatore e fruitore viene instaurato in mutua autenticazione utilizzando il protocollo TLS, secondo le modalità specificate alla sezione Elenco degli algoritmi.

A: Richiesta

  1. Il fruitore costruisce un messaggio di richiesta.
  2. Il fruitore spedisce utilizzando canale sicuro stabilito con il il messaggio di richiesta all’interfaccia di servizio dell’erogatore.

B: Risposta

  1. L’erogatore elabora il messaggio e restituisce un risultato.

Come indicato in RFC 5246 l’impiego del protocollo TLS garantisce a livello di canale:

  • l’autenticazione di erogatore e fruitore identificati mediante certificati X.509
  • la confidenzialità dei dati scambiati
  • l’integrità dei dati scambiati

L’impiego del protocollo TLS 1.2 o maggiore, mitiga il rischio di:

  • Replay Attack
  • Spoofing