ims-volte-vowifi
/
strongswan
1
0
Fork 0
Code Pull Requests Releases Activity

updated RFCs/drafts

Browse Source
laforge/swu
Martin Willi 15 years ago
parent 513f20156a
commit d6bd078a65
5 changed files with 3977 additions and 12264 deletions
Show all changes Ignore whitespace when comparing lines Ignore changes in amount of whitespace Ignore changes in whitespace at EOL
Show Stats Download Patch File Download Diff File
  1. 3250
      doc/standards/draft-eronen-ipsec-ikev2-clarifications-09.txt
  2. 6720
      doc/standards/draft-hoffman-ikev2-1-00.txt
  3. 4244
      doc/standards/draft-hoffman-ikev2bis-03.txt
  4. 1401
      doc/standards/draft-sheffer-ipsec-failover-03.txt
  5. 626
      doc/standards/rfc4806.txt

3250
doc/standards/draft-eronen-ipsec-ikev2-clarifications-09.txt
View File

File diff suppressed because it is too large Load Diff

6720
doc/standards/draft-hoffman-ikev2-1-00.txt
View File

File diff suppressed because it is too large Load Diff

4244
doc/standards/draft-hoffman-ikev2bis-00.txt → doc/standards/draft-hoffman-ikev2bis-03.txt
View File

File diff suppressed because it is too large Load Diff

1401
doc/standards/draft-sheffer-ipsec-failover-03.txt
View File

File diff suppressed because it is too large Load Diff

626
doc/standards/draft-myers-ikev2-ocsp-03.txt → doc/standards/rfc4806.txt
Unescape View File

@ -1,65 +1,43 @@
Network Working Group M. Myers
Internet-Draft TraceRoute Security LLC
Expires: January 12, 2007 H. Tschofenig
Siemens
July 11, 2006
OCSP Extensions to IKEv2
draft-myers-ikev2-ocsp-03.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Network Working Group M. Myers
Request for Comments: 4806 TraceRoute Security LLC
Category: Standards Track H. Tschofenig
Siemens Networks GmbH & Co KG
February 2007
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
Online Certificate Status Protocol (OCSP) Extensions to IKEv2
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Status of This Memo
This Internet-Draft will expire on January 12, 2007.
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Copyright (C) The IETF Trust (2006).
Abstract
While IKEv2 supports public key based authentication (PKI), the
corresponding use of in-band CRLs is problematic due to unbounded CRL
size. The size of an OCSP response is however well-bounded and
small. This document defines the "OCSP Content" extension to IKEv2.
A CERTREQ payload with "OCSP Content" identifies one or more trusted
OCSP responders and is a request for inclusion of an OCSP response in
the IKEv2 handshake. A cooperative recipient of such a request
Myers & Tschofenig Expires January 12, 2007 [Page 1]
Internet-Draft OCSP Extensions to IKEv2 July 2006
responds with a CERT payload containing the appropriate OCSP
response. This content is recognizable via the same "OCSP Content"
identifier.
While the Internet Key Exchange Protocol version 2 (IKEv2) supports
public key based authentication, the corresponding use of in-band
Certificate Revocation Lists (CRL) is problematic due to unbounded
CRL size. The size of an Online Certificate Status Protocol (OCSP)
response is however well-bounded and small. This document defines
the "OCSP Content" extension to IKEv2. A CERTREQ payload with "OCSP
Content" identifies zero or more trusted OCSP responders and is a
request for inclusion of an OCSP response in the IKEv2 handshake. A
cooperative recipient of such a request responds with a CERT payload
containing the appropriate OCSP response. This content is
recognizable via the same "OCSP Content" identifier.
When certificates are used with IKEv2, the communicating peers need a
mechanism to determine the revocation status of the peer's
@ -70,35 +48,6 @@ Internet-Draft OCSP Extensions to IKEv2 July 2006
outside of an enterprise network.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Extension Definition . . . . . . . . . . . . . . . . . . . . . 5
3.1. OCSP Request . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. OCSP Response . . . . . . . . . . . . . . . . . . . . . . 5
4. Extension Requirements . . . . . . . . . . . . . . . . . . . . 6
4.1. OCSP Request . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. OCSP Response . . . . . . . . . . . . . . . . . . . . . . 6
5. Examples and Discussion . . . . . . . . . . . . . . . . . . . 8
5.1. Peer to Peer . . . . . . . . . . . . . . . . . . . . . . . 8
5.2. Extended Authentication Protocol (EAP) . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
9. Normative References . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14
@ -106,31 +55,47 @@ Table of Contents
Myers & Tschofenig Standards Track [Page 1]
RFC 4806 OCSP Extensions to IKEv2 February 2007
Myers & Tschofenig Expires January 12, 2007 [Page 2]
Internet-Draft OCSP Extensions to IKEv2 July 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Extension Definition . . . . . . . . . . . . . . . . . . . . . 4
3.1. OCSP Request . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. OCSP Response . . . . . . . . . . . . . . . . . . . . . . 5
4. Extension Requirements . . . . . . . . . . . . . . . . . . . . 5
4.1. Request for OCSP Support . . . . . . . . . . . . . . . . . 5
4.2. Response to OCSP Support . . . . . . . . . . . . . . . . . 6
5. Examples and Discussion . . . . . . . . . . . . . . . . . . . 6
5.1. Peer to Peer . . . . . . . . . . . . . . . . . . . . . . . 6
5.2. Extended Authentication Protocol (EAP) . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
9. Normative References . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
Version 2 of the Internet Key Exchange (IKE) protocol [IKEv2]
supports a range of authentication mechanisms, including the use of
public key based authentication. Confirmation of certificate
reliability is essential to achieve the security assurances public
key cryptography provides. One fundamental element of such
reliability is essential in order to achieve the security assurances
public key cryptography provides. One fundamental element of such
confirmation is reference to certificate revocation status (see
[RFC3280] for additional detail).
The historic means of determining certificate revocation status is
The traditional means of determining certificate revocation status is
through the use of Certificate Revocation Lists (CRLs). IKEv2 allows
CRLs to be exchanged in-band via the CERT payload.
CRLs can however grow unbounded in size. Many real-world examples
However, CRLs can grow unbounded in size. Many real-world examples
exist to demonstrate the impracticality of including a multi-megabyte
file in an IKE exchange. This constraint is particularly acute in
bandwidth limited environments (e.g., mobile communications). The
bandwidth-limited environments (e.g., mobile communications). The
net effect is exclusion of in-band CRLs in favor of out-of-band (OOB)
acquisition of these data, should they even be used at all.
@ -138,8 +103,18 @@ Internet-Draft OCSP Extensions to IKEv2 July 2006
revocation data requires use of IPsec (and therefore IKE) to
establish secure and authorized access to the CRLs of an IKE
participant. Such network access deadlock further contributes to a
reduced reliance on certificate revocation status in favor of blind
trust.
reduced reliance on the status of certificate revocations in favor of
blind trust.
Myers & Tschofenig Standards Track [Page 2]
RFC 4806 OCSP Extensions to IKEv2 February 2007
OCSP [RFC2560] offers a useful alternative. The size of an OCSP
response is bounded and small and therefore suitable for in-band
@ -148,39 +123,39 @@ Internet-Draft OCSP Extensions to IKEv2 July 2006
This document defines an extension to IKEv2 that enables the use of
OCSP for in-band signaling of certificate revocation status. A new
content encoding is defined for use in the CERTREQ and CERT payloads.
A CERTREQ payload with "OCSP Content" identifies one or more trusted
A CERTREQ payload with "OCSP Content" identifies zero or more trusted
OCSP responders and is a request for inclusion of an OCSP response in
the IKEv2 handshake. A cooperative recipient of such a request
responds with a CERT payload containing the appropriate OCSP
response. This content is recognizable via the same "OCSP Content"
identifier.
Myers & Tschofenig Expires January 12, 2007 [Page 3]
Internet-Draft OCSP Extensions to IKEv2 July 2006
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
This document defines the following terms:
OCSP request:
An OCSP request refers to the CERTREQ payload that contains a new
content encoding, referred to as OCSP Content, that conforms to
the definition and behavior specified in Section 3.1.
OCSP response:
An OCSP response refers to the CERT payload that contains a new
content encoding, referred to as OCSP Content, that conforms to
the definition and behavior specified in Section 3.2.
OCSP responder:
The term OCSP responder refers to the entity that accepts requests
from an OCSP client and returns responses as defined in [RFC2560].
Note that the OCSP responder does not refer to the party that
sends the CERT message.
@ -192,37 +167,9 @@ Internet-Draft OCSP Extensions to IKEv2 July 2006
Myers & Tschofenig Expires January 12, 2007 [Page 4]
Myers & Tschofenig Standards Track [Page 3]
Internet-Draft OCSP Extensions to IKEv2 July 2006
RFC 4806 OCSP Extensions to IKEv2 February 2007
3. Extension Definition
@ -238,13 +185,31 @@ Internet-Draft OCSP Extensions to IKEv2 July 2006
3.1. OCSP Request
A value of OCSP Content (14) in the Cert Encoding field of a CERTREQ
Payload indicates the presence of one or more OCSP Responder
Payload indicates the presence of zero or more OCSP responder
certificate hashes in the Certificate Authority field of the CERTREQ
payload.
payload. Section 2.2 of [RFC2560] defines responses, which belong to
one of the following three groups:
(a) the CA who issued the certificate
(b) a Trusted Responder whose public key is trusted by the requester
(c) a CA Designated Responder (Authorized Responder) who holds a
specially marked certificate issued directly by the CA,
indicating that the responder may issue OCSP responses for that
CA
In case of (a), the use of hashes in the CERTREQ message is not
needed since the OCSP response is signed by the CA who issued the
certificate. In case of (c), the OCSP response is signed by the CA
Designated Responder whereby the sender of the CERTREQ message does
not know the public key in advance. The presence of OCSP Content in
a CERTREQ message will identify one or more OCSP responders trusted
by the sender in case of (b).
The presence of OCSP Content (14) in a CERTREQ message:
1. identifies one or more OCSP responders trusted by the sender;
1. identifies zero or more OCSP responders trusted by the sender;
2. notifies the recipient of sender's support for the OCSP extension
to IKEv2; and
@ -252,45 +217,39 @@ Internet-Draft OCSP Extensions to IKEv2 July 2006
3. notifies the recipient of sender's desire to receive OCSP
confirmation in a subsequent CERT payload.
3.2. OCSP Response
A value of OCSP Content (14) in the Cert Encoding field of a CERT
Payload indicates the presence of an OCSP Response in the Certificate
Data field of the CERT payload.
Correlation between an OCSP Response CERT payload and a corresponding
CERT payload carrying a certificate can be achieved by matching the
OCSP response CertID field to the certificate. See [RFC2560] for the
definition of OCSP response content.
Myers & Tschofenig Standards Track [Page 4]
RFC 4806 OCSP Extensions to IKEv2 February 2007
3.2. OCSP Response
Myers & Tschofenig Expires January 12, 2007 [Page 5]
Internet-Draft OCSP Extensions to IKEv2 July 2006
A value of OCSP Content (14) in the Cert Encoding field of a CERT
Payload indicates the presence of an OCSP response in the Certificate
Data field of the CERT payload.
Correlation between an OCSP response CERT payload and a corresponding
CERT payload carrying a certificate can be achieved by matching the
OCSP response CertID field to the certificate. See [RFC2560] for the
definition of OCSP response content.
4. Extension Requirements
4.1. OCSP Request
4.1. Request for OCSP Support
Section 3.7 of [IKEv2] allows for the concatenation of trust anchor
hashes as the Certification Authority value of a single CERTREQ
message. There is no means however to indicate which among those
hashes relates to the certificate of a trusted OCSP responder.
hashes, if present, relates to the certificate of a trusted OCSP
responder.
Therefore an OCSP Request as defined in Section 3.1 above SHALL be
Therefore, an OCSP request, as defined in Section 3.1 above, is
transmitted separate from any other CERTREQ payloads in an IKEv2
exchange.
@ -299,99 +258,47 @@ Internet-Draft OCSP Extensions to IKEv2 July 2006
to the method documented in Section 3.7 of [IKEv2] regarding the
assembly of multiple trust anchor hashes.
The Certification Authority value in an OCSP Request CERTREQ SHALL be
The Certification Authority value in an OCSP request CERTREQ SHALL be
computed and produced in a manner identical to that of trust anchor
hashes as documented in Section 3.7 of [IKEv2].
Upon receipt of an OCSP Response CERT payload corresponding to a
prior OCSP Request CERTREQ, the CERTREQ sender SHALL incorporate the
Upon receipt of an OCSP response CERT payload corresponding to a
prior OCSP request CERTREQ, the CERTREQ sender SHALL incorporate the
OCSP response into path validation logic defined by [RFC3280].
The sender of an OCSP Request CERTREQ MAY abort an IKEv2 exchange if
either:
Note that the lack of an OCSP response CERT payload after sending an
OCSP request CERT payload might be an indication that this OCSP
extension is not supported. As a result, it is recommended that
nodes be configured to require a response only if it is known that
all peers do in fact support this extension. Otherwise, it is
recommended that the nodes be configured to try OCSP and, if there is
no response, attempt to determine certificate revocation status by
some other means.
1. the corresponding OCSP Response CERT payload indicates that the
subject certificate is revoked; OR
2. the corresponding OCSP Response CERT payload indicates an OCSP
error (e.g., malformedRequest, internalError, tryLater,
sigRequired, unauthorized, etc.).
The sender of an OCSP Request CERTREQ SHOULD accept an IKEv2 exchange
if a corresponding OCSP Response CERT payload is not received. This
might be an indication that this OCSP extension is not supported.
4.2. OCSP Response
Upon receipt of an OCSP Request CERTREQ payload, the recipient SHOULD
acquire the related OCSP-based assertion and produce and transmit an
OCSP Response CERT payload corresponding to the certificate needed to
verify its signature on IKEv2 payloads.
An OCSP Response CERT payload SHALL be transmitted separate from any
Myers & Tschofenig Expires January 12, 2007 [Page 6]
Myers & Tschofenig Standards Track [Page 5]
Internet-Draft OCSP Extensions to IKEv2 July 2006
other CERT payload in an IKEv2 exchange.
The means by which an OCSP response may be acquired for production of
an OCSP Response CERT payload is out of scope of this document.
The structure and encoding of the Certificate Data field of an OCSP
Response CERT payload SHALL be identical to that defined in
[RFC2560].
RFC 4806 OCSP Extensions to IKEv2 February 2007
4.2. Response to OCSP Support
Upon receipt of an OCSP request CERTREQ payload, the recipient SHOULD
acquire the related OCSP-based assertion and produce and transmit an
OCSP response CERT payload corresponding to the certificate needed to
verify its signature on IKEv2 payloads.
An OCSP response CERT payload is transmitted separate from any other
CERT payload in an IKEv2 exchange.
Myers & Tschofenig Expires January 12, 2007 [Page 7]
Internet-Draft OCSP Extensions to IKEv2 July 2006
The means by which an OCSP response may be acquired for production of
an OCSP response CERT payload is out of scope of this document.
The Certificate Data field of an OCSP response CERT payload SHALL
contain a DER-encoded OCSPResponse structure as defined in [RFC2560].
5. Examples and Discussion
@ -407,7 +314,6 @@ Internet-Draft OCSP Extensions to IKEv2 July 2006
peer-to-peer exchange defined in Section 1.2 of [IKEv2] is as
follows. Messages are numbered for ease of reference.
Initiator Responder
----------- -----------
(1) HDR, SAi1, KEi, Ni -->
@ -424,46 +330,72 @@ Internet-Draft OCSP Extensions to IKEv2 July 2006
CERT(OCSP Response),
AUTH, SAr2, TSi, TSr}
In (2) Responder sends an OCSP Request CERTREQ payload identifying
one or more OCSP responders trusted by Responder. In response,
Initiator sends in (3) both a CERT payload carrying its certificate
and an OCSP Response CERT payload covering that certificate. In (3)
Initiator also requests an OCSP response via the OCSP Request CERTREQ
payload. In (4) Responder returns its certificate and a separate
OCSP Response CERT payload covering that certificate.
OCSP Extensions to Baseline IKEv2
It is important to note that in this scenario, the Responder in (2)
does not yet possess the Initiator's certificate and therefore cannot
form an OCSP request. [RFC2560] allows for pre-produced responses.
It is thus easily inferred that OCSP responses can be produced in the
absence of a corresponding request (OCSP nonces notwithstanding). In
such instances OCSP Requests are simply index values into these data.
It is also important in extending IKEv2 towards OCSP in this scenario
that the Initiator has certain knowledge that the Responder is
Myers & Tschofenig Expires January 12, 2007 [Page 8]
Myers & Tschofenig Standards Track [Page 6]
Internet-Draft OCSP Extensions to IKEv2 July 2006
RFC 4806 OCSP Extensions to IKEv2 February 2007
In (2), Responder sends an OCSP request CERTREQ payload identifying
zero or more OCSP responders trusted by the Responder. In response,
Initiator sends in (3) both a CERT payload carrying its certificate
and an OCSP response CERT payload covering that certificate. In (3),
Initiator also requests an OCSP response via the OCSP request CERTREQ
payload. In (4), the Responder returns its certificate and a
separate OCSP response CERT payload covering that certificate.
It is important to note that in this scenario, the Responder in (2)
does not yet possess the Initiator's certificate and therefore cannot
form an OCSP request as defined in [RFC2560]. To bypass this
problem, hashes are used as defined in Section 4.1. In such
instances, OCSP Requests are simply index values into these data.
Thus, it is easily inferred that OCSP responses can be produced in
the absence of a corresponding request (provided that OCSP nonces are
not used, see Section 6).
It is also important in extending IKEv2 toward OCSP in this scenario
that the Initiator has certain knowledge that the Responder is
capable of and willing to participate in the extension. Yet the
Responder will only trust one or more OCSP responder signatures.
These factors motivate the definition of OCSP Responder Hash
These factors motivate the definition of OCSP responder hash
extension.
5.2. Extended Authentication Protocol (EAP)
Another scenario of pressing interest is the use of EAP to
accommodate multiple end users seeking enterprise access to an IPsec
gateway. As with the preceding section, the following illustration
gateway. Note that OCSP is used for the certificate status check of
the server side IKEv2 certificate and not for certificates that may
be used within EAP methods (either by the EAP peer or the EAP
server). As with the preceding section, the following illustration
is extracted from [IKEv2]. In the event of a conflict between this
document and[IKEv2] regarding these illustrations, [IKEv2] SHALL
document and [IKEv2] regarding these illustrations, [IKEv2] SHALL
dominate.
Myers & Tschofenig Standards Track [Page 7]
RFC 4806 OCSP Extensions to IKEv2 February 2007
Initiator Responder
----------- -----------
(1) HDR, SAi1, KEi, Ni -->
@ -484,35 +416,19 @@ Internet-Draft OCSP Extensions to IKEv2 July 2006
(8) <-- HDR, SK {AUTH, SAr2, TSi,
TSr }
In the EAP scenario, messages (5) through (8) are not relevant to
this document. Note that while [IKEv2] allows for the optional
inclusion of a CERTREQ in (2), this document asserts no need of its
use. It is assumed that environments including this optional payload
and yet wishing to implement the OCSP extension to IKEv2 are
sufficiently robust as to accommodate this redundant payload.
Myers & Tschofenig Expires January 12, 2007 [Page 9]
Internet-Draft OCSP Extensions to IKEv2 July 2006
OCSP Extensions to EAP in IKEv2
In the EAP scenario, messages (5) through (8) are not relevant to
this document.
6. Security Considerations
For the reasons noted above, OCSP request as defined in Section 3.1
is used in place of OCSP request syntax to trigger production and
transmission of an OCSP response. OCSP as defined in [RFC2560] may
contain a nonce request extension to improve security against replay
attacks (see Section 4.4.1 of [RFC2560] for further details). The
OCSP Request defined by this document cannot accommodate nonces.
For the reasons noted above, an OCSP request, as defined in Section
3.1, is used in place of an OCSP request syntax to trigger production
and transmission of an OCSP response. OCSP, as defined in [RFC2560],
may contain a nonce request extension to improve security against
replay attacks (see Section 4.4.1 of [RFC2560] for further details).
The OCSP request defined by this document cannot accommodate nonces.
[RFC2560] deals with this aspect by allowing pre-produced responses.
[RFC2560] points to this replay vulnerability and indicates: "The use
@ -522,16 +438,7 @@ Internet-Draft OCSP Extensions to IKEv2 July 2006
evaluate the benefit of precomputed responses against the probability
of a replay attack and the costs associated with its successful
execution." Nodes SHOULD make the required freshness of an OCSP
Response configurable.
response configurable.
@ -540,25 +447,9 @@ Internet-Draft OCSP Extensions to IKEv2 July 2006
Myers & Tschofenig Expires January 12, 2007 [Page 10]
Myers & Tschofenig Standards Track [Page 8]
Internet-Draft OCSP Extensions to IKEv2 July 2006
RFC 4806 OCSP Extensions to IKEv2 February 2007
7. IANA Considerations
@ -566,63 +457,20 @@ Internet-Draft OCSP Extensions to IKEv2 July 2006
This document defines one new field type for use in the IKEv2 Cert
Encoding field of the Certificate Payload format. Official
assignment of the "OCSP Content" extension to the Cert Encoding table
of Section 3.6 of [IKEv2] needs to be acquired from IANA.
of Section 3.6 of [IKEv2] has been acquired from IANA.
Certificate Encoding Value
-------------------- -----
OCSP Content 14
Myers & Tschofenig Expires January 12, 2007 [Page 11]
Internet-Draft OCSP Extensions to IKEv2 July 2006
8. Acknowledgements
The authors would like to thank Russ Housley for his support.
Additionally, we would like to thank Pasi Eronen, Nicolas Williams,
Liqiang (Larry) Zhu, Lakshminath Dondeti and Paul Hoffman for their
review.
Liqiang (Larry) Zhu, Lakshminath Dondeti, and Paul Hoffman for their
review. Pasi gave us invaluable last-call comments. We would also
like to thank Tom Taylor for his Gen-ART review. Jari Arkko gave us
IESG review comments.
9. Normative References
@ -655,22 +503,9 @@ Internet-Draft OCSP Extensions to IKEv2 July 2006
Myers & Tschofenig Expires January 12, 2007 [Page 12]
Myers & Tschofenig Standards Track [Page 9]
Internet-Draft OCSP Extensions to IKEv2 July 2006
RFC 4806 OCSP Extensions to IKEv2 February 2007
Authors' Addresses
@ -678,17 +513,16 @@ Authors' Addresses
Michael Myers
TraceRoute Security LLC
Email: mmyers@fastq.com
EMail: mmyers@fastq.com
Hannes Tschofenig
Siemens
Siemens Networks GmbH & Co KG
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
Email: Hannes.Tschofenig@siemens.com
EMail: Hannes.Tschofenig@siemens.com
URI: http://www.tschofenig.com
@ -724,12 +558,29 @@ Authors' Addresses
Myers & Tschofenig Expires January 12, 2007 [Page 13]
Myers & Tschofenig Standards Track [Page 10]
Internet-Draft OCSP Extensions to IKEv2 July 2006
RFC 4806 OCSP Extensions to IKEv2 February 2007
Full Copyright Statement
Intellectual Property Statement
Copyright (C) The IETF Trust (2007).
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, THE IETF TRUST 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
@ -753,33 +604,16 @@ Intellectual Property Statement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Disclaimer of Validity
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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Funding for the RFC Editor function is currently provided by the
Internet Society.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Myers & Tschofenig Expires January 12, 2007 [Page 14]
Myers & Tschofenig Standards Track [Page 11]
Write Preview
Loading…
Cancel
Save