Searched refs:Phase (Results 1 – 25 of 40) sorted by relevance
12
| /netbsd/src/crypto/dist/ipsec-tools/src/racoon/rfc/ |
| D | draft-ietf-ipsec-isakmp-hybrid-auth-05.txt | 45 used within Phase 1 of the Internet Key Exchange (IKE). The proposed
51 establish, at the end of Phase 1, an IKE SA which is unidirectionally
53 Phase 1 is immediately followed by an X-Auth Exchange [XAUTH]. The
99 Mutual authentication within Phase 1 is now discussed in [XAUTH].
104 during Phase 1.
124 is based on Phase 1 Exchange, while the latter authenticates the
191 two stages. In the first stage, Phase 1 Exchange is being utilized to
213 the Phase 1 authentication methods described in [XAUTH] should be
222 authentication method. At the end of Phase 1 the established IKE SA
288 stage is a Phase 1 Exchange used to authenticate the Edge Device. The
[all …]
|
| D | rfc3947.txt | 67 3. Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
89 needed in IKE Phase 1 for NAT-Traversal support. This includes
133 3. Phase 1
136 the path between the two IKE peers occurs in IKE [RFC2409] Phase 1.
178 exchange of vendor ID payloads. In the first two messages of Phase
268 The following example is of a Phase 1 exchange using NAT-Traversal in
287 The following example is of Phase 1 exchange using NAT-Traversal in
354 Similarly, if the responder has to rekey the Phase 1 SA, then the
368 Here is an example of a Phase 1 exchange using NAT-Traversal in Main
436 After Phase 1, both ends know whether there is a NAT present between
|
| D | draft-ietf-ipsec-nat-t-ike-08.txt | 67 3. Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
90 needed in IKE Phase 1 for NAT-Traversal support. This includes detecting
131 3. Phase 1
134 the path between the two IKE peers occurs in IKE [RFC-2409] Phase 1.
162 exchange of vendor ID payloads. In the first two messages of Phase 1,
250 An example of a Phase 1 exchange using NAT-Traversal in Main Mode
262 An example of Phase 1 exchange using NAT-Traversal in Aggressive Mode
323 Similarly, if the responder needs to rekey the Phase 1 SA, then the
337 Here is an example of a Phase 1 exchange using NAT-Traversal in Main
404 After the Phase 1 both ends know if there is a NAT present between them.
|
| D | rfc2409.txt | 51 7.1 Phase 1 with Main Mode........................................ 23
52 7.2 Phase 2 with Quick Mode....................................... 25
268 Phase 1 is where the two ISAKMP peers establish a secure,
274 Phase 2 is where Security Associations are negotiated on behalf of
543 the content and use of messages for Phase 1 Modes, but not their
544 intent. When using public keys for authentication, the Phase 1
547 Phase 1 exchanges with different authentication options.
549 5.1 IKE Phase 1 Authenticated With Signatures
623 5.2 Phase 1 Authenticated With Public Key Encryption
702 5.3 Phase 1 Authenticated With a Revised Mode of Public Key Encryption
[all …]
|
| D | rfc3715.txt | 204 Protocol (IKE) Phase 1 [RFC2409] or Phase 2, modification of the
210 In order to avoid use of IP addresses as IKE Phase 1 and Phase 2
217 certificates are exchanged in Phase 1. While use of USER_FQDN or
231 Since the source address in the Phase 2 identifier is often used
250 Phase 2 identifiers, they can negotiate overlapping SPD entries
412 problems with re-keying, since Phase 1 re-keys typically will not
766 claimed within the original IKE Phase 1 and Phase 2 security
|
| D | draft-ietf-ipsec-nat-t-ike-00.txt | 66 3. Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
106 3. Phase 1
114 exchange of vendor strings; in Phase 1 two first messages, the vendor id
221 After the Phase 1 both ends know if there is a NAT present between. The
|
| D | draft-ietf-ipsec-nat-t-ike-01.txt | 66 3. Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
106 3. Phase 1
141 exchange of vendor strings; in Phase 1 two first messages, the vendor id
247 After the Phase 1 both ends know if there is a NAT present between. The
|
| D | rfc2408.txt | 1133 Phase 1 exchange, prior to completing the establishment of an SA.
1301 MUST be reset after the Phase 1 negotiation. If set(1), the
1307 original ISAKMP Phase 2 SA negotiation. This is done to
1309 Notify Message can be associated with the correct Phase 2 SA.
1321 Phase 2 SA negotiation message following a Phase 1 exchange or
1322 encrypted traffic following a Phase 2 exchange. Handling of
1326 Phase 2 SA negotiation message or encrypted traffic), then
1338 4.8 states that a Phase 2 Informational Exchange MUST be sent
1354 identify protocol state during Phase 2 negotiations. This value
1355 is randomly generated by the initiator of the Phase 2
[all …]
|
| D | rfc2407.txt | 79 o define the syntax for DOI-specific SA Attributes (Phase II)
140 Identification Payload in at least one of the Phase I Oakley
306 simultaneous negotiation of multiple Phase II security protocol
327 Phase I of the ISAKMP protocol. The specific protection mechanism
365 As part of an ISAKMP Phase I negotiation, the initiator's choice of
369 lists the defined ISAKMP Phase I Transform Identifiers for the
650 The following SA attribute definitions are used in Phase II of an IKE
1031 During Phase I negotiations, the ID port and protocol fields MUST be
1614 o added restriction for ID port/protocol values for Phase I
|
| D | draft-ietf-ipsec-nat-t-ike-03.txt | 66 3. Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
109 3. Phase 1
144 exchange of vendor strings; in Phase 1 two first messages, the vendor id
375 After the Phase 1 both ends know if there is a NAT present between. The
|
| D | draft-ietf-ipsec-nat-t-ike-06.txt | 66 3. Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
113 3. Phase 1
150 exchange of vendor strings; in Phase 1 two first messages, the vendor id
380 After the Phase 1 both ends know if there is a NAT present between. The
|
| D | draft-ietf-ipsec-nat-t-ike-02.txt | 66 3. Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
109 3. Phase 1
144 exchange of vendor strings; in Phase 1 two first messages, the vendor id
375 After the Phase 1 both ends know if there is a NAT present between. The
|
| D | draft-ietf-ipsec-nat-t-ike-07.txt | 66 3. Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
112 3. Phase 1
149 exchange of vendor strings; in Phase 1 two first messages, the vendor id
380 After the Phase 1 both ends know if there is a NAT present between. The
|
| D | draft-ietf-ipsec-nat-t-ike-05.txt | 66 3. Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
113 3. Phase 1
150 exchange of vendor strings; in Phase 1 two first messages, the vendor id
380 After the Phase 1 both ends know if there is a NAT present between. The
|
| D | draft-dukes-ike-mode-cfg-02.txt | 621 the Phase I Security Association has been set up and that the entire
622 exchange be protected by that Phase I SA. Thus the exchange is as
623 secure as any Phase II SA negotiation.
|
| D | draft-ietf-ipsec-nat-t-ike-04.txt | 66 3. Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
113 3. Phase 1
151 exchange of vendor strings; in Phase 1 two first messages, the vendor id
382 After the Phase 1 both ends know if there is a NAT present between. The
|
| /netbsd/src/external/bsd/wpa/dist/hostapd/ |
| D | hostapd.eap_user | 23 # EAP-PEAP, EAP-TTLS, and EAP-FAST require Phase 2 configuration.
41 # version based on the Phase 1 identity. Without this flag, the EAP
58 # Phase 1 users
85 # Phase 2 (tunnelled within EAP-PEAP or EAP-TTLS) users
|
| D | ChangeLog | 754 * EAP-FAST server: piggyback Phase 2 start with the end of Phase 1
871 * added peer identity into EAP-FAST PAC-Opaque and skip Phase 2
873 * added support for EAP Sequences in EAP-FAST Phase 2
880 * added support for fragmenting EAP-TTLS/PEAP/FAST Phase 2 (tunneled)
903 phase 2 to allow EAP-SIM and EAP-AKA to be used as the Phase 2 method
1179 Phase 1 identity
1199 * added support for configuring multiple allowed EAP types for Phase 2
1207 * added support for configuring list of EAP methods for Phase 1 so that
|
| /netbsd/src/crypto/dist/ipsec-tools/src/racoon/samples/ |
| D | racoon.conf.sample-natt | 58 # Phase 1 configuration (for ISAKMP SA)
89 # Phase 2 proposal (for IPsec SA)
|
| /netbsd/src/external/bsd/wpa/dist/wpa_supplicant/ |
| D | eap_testing.txt | 236 packet from Supplicant looks like the one sent in the Phase 1. The
237 server generates a valid looking reply in the same way as in Phase
256 seems to get confused and fails to send proper Phase 2 data.
265 seems to get confused and fails to send proper Phase 2 data.
306 (Failed to decrypt Phase 2 data)
|
| /netbsd/src/share/locale/ctype/ |
| D | ja_JP.SJIS.src | 6 * (C) Sin'ichiro MIYATANI / Phase One, Inc
19 * This product includes software developed by Phase One, Inc.
20 * 4. The name of Phase One, Inc. may be used to endorse or promote products
|
| /netbsd/src/external/gpl3/gcc/dist/libgcc/ |
| D | unwind.inc | 35 _Unwind_Resume and we'll continue Phase 2 there. */
96 /* Phase 1: Search. Unwind the stack, calling the personality routine
|
| /netbsd/src/external/bsd/openldap/dist/doc/rfc/ |
| D | rfc3928.txt | 93 4.3.1. Returning Results During the Persistent Phase . . 15
94 4.3.2. No Mixing of Sync Phase with Persist Phase. . . . 16
95 4.3.3. Returning Updated Results During the Sync Phase . 16
123 5.6. Multiple Copies of Same Entry During Sync Phase. . . . . 21
131 6.4. Persist Phase Response Time. . . . . . . . . . . . . . . 23
832 4.3.1. Returning Results During the Persistent Phase
847 4.3.2. No Mixing of Sync Phase with Persist Phase
856 4.3.3. Returning Updated Results During the Sync Phase
1158 5.6. Multiple Copies of Same Entry During Sync Phase
1263 6.4. Persist Phase Response Time
|
| /netbsd/src/sys/arch/ |
| D | README | 8 amigappc powerpc 20000525 Phase 5 Amiga
|
| /netbsd/src/sys/dev/microcode/aic7xxx/ |
| D | aic79xx.reg | 1718 * SCSI Phase
2586 * 960MHz Phase-Locked Loop Control 0
2611 * 960MHz Phase-Locked Loop Control 1
2651 * 960-MHz Phase-Locked Loop Test Count
2661 * 400-MHz Phase-Locked Loop Control 0
2687 * 400-MHz Phase-Locked Loop Control 1
2709 * 400-MHz Phase-Locked Loop Test Count
|
12