Internet Engineering Task Force John Shriver
IP Security Working Group Intel Corporation
Internet Draft October 3, 2001
IPsec DOI Textual Conventions MIB
<draft-ietf-ipsec-doi-tc-mib-05.txt>
Status of this Memo
This document is a submission to the IETF Internet Protocol Security
(IPsec) Working Group. Comments are solicited and should be
addressed to the working group mailing list (ipsec@lists.tislabs.com)
or to the editor.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. 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.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or made obsolete 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
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Distribution of this memo is unlimited.
Copyright Notice
This document is a product of the IETF's IPsec Working Group.
Copyright (C) The Internet Society (2001). All Rights Reserved.
Table of Contents
1 Introduction .............................................. 2
2 The SNMP Network Management Framework ..................... 2
3 Discussion ................................................ 3
IPsec Working Group [Page 1]
Internet Draft IPsec DOI Textual Conventions MIB October 2001
4 MIB Definitions ........................................... 4
5 Security Considerations ................................... 19
6 IANA Considerations ....................................... 19
7 Acknowledgements .......................................... 19
8 Revision History .......................................... 19
9 References ................................................ 20
10 Author's Address ......................................... 21
1. Introduction
This memo defines textual conventions for use in monitoring, status,
and configuration MIBs for IPsec. It includes a MIB module that
defines those textual conventions.
2. The SNMPv2 Network Management Framework
The SNMP Management Framework presently consists of five major
components:
o An overall architecture, described in RFC 2571 [2571].
o Mechanisms for describing and naming objects and events for the
purpose of management. The first version of this Structure of
Management Information (SMI) is called SMIv1 and described in
STD 16, RFC 1155 [1155], STD 16, RFC 1212 [1212] and RFC 1215
[1215]. The second version, called SMIv2, is described in
STD 58, RFC 2578 [2578], RFC 2579 [2579] and RFC 2580 [2580].
o Message protocols for transferring management information. The
first version of the SNMP message protocol is called SNMPv1 and
described in STD 15, RFC 1157 [1157]. A second version of the
SNMP message protocol, which is not an Internet standards track
protocol, is called SNMPv2c and described in RFC 1901 [1901] and
RFC 1906 [1906]. The third version of the message protocol is
called SNMPv3 and described in RFC 1906 [1906], RFC 2572 [2572]
and RFC 2574 [2574].
o Protocol operations for accessing management information. The
first set of protocol operations and associated PDU formats is
described in STD 15, RFC 1157 [1157]. A second set of protocol
operations and associated PDU formats is described in RFC 1905
[1905].
o A set of fundamental applications described in RFC 2573 [2573]
and the view-based access control mechanism described in
RFC 2575 [2575].
IPsec Working Group [Page 2]
Internet Draft IPsec DOI Textual Conventions MIB October 2001
A more detailed introduction to the current SNMP Management Framework
can be found in RFC 2570 [2570].
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. Objects in the MIB are
defined using the mechanisms defined in the SMI.
This memo specifies a MIB module that is compliant to the SMIv2. A
MIB conforming to the SMIv1 can be produced through the appropriate
translations. The resulting translated MIB must be semantically
equivalent, except where objects or events are omitted because no
translation is possible (use of Counter64). Some machine readable
information in SMIv2 will be converted into textual descriptions in
SMIv1 during the translation process. However, this loss of machine
readable information is not considered to change the semantics of the
MIB.
3. Discussion
The IPsec architecture [SECARCH] defines protocols for dynamic key
management. These are based on the Internet Security Association and
Key Management Protocol [ISAKMP].
ISAKMP defines the concept of Domains of Interpretation (DOI). The
IPsec architecture has defined the Internet IP Security Domain of
Interptetation for ISAKMP [IPDOI].
The IPsec architecture defines the Internet Key Exchange [IKE]. The
use of this protocol is indicated by one of the constants in the
IPsec DOI.
This MIB defines textual conventions for the constants defined in
ISAKMP, the IPsec DOI, and IKE.
These are defined in a seperate MIB for two reasons.
o There will be variables with a syntax corresponding to these
textual conventions in numberous MIBs that will be defined for
the IPsec architecture.
o All of the numbers defined in these textual conventions are in
"magic number" spaces that are managed by the IANA.
If these conventions were part of the relevant MIBs, those MIBs would
be constantly out of date. By placing them in a seperate MIB, that
MIB can be maintained by the IANA simultaneously with assigning new
values.
IPsec Working Group [Page 3]
Internet Draft IPsec DOI Textual Conventions MIB October 2001
4. MIB Definitions
IPSEC-ISAKMP-IKE-DOI-TC DEFINITIONS ::= BEGIN
IMPORTS
-- delete next line before release
experimental,
MODULE-IDENTITY, Unsigned32 FROM SNMPv2-SMI
-- uncomment next line before release
-- mib-2 FROM RFC1213-MIB
TEXTUAL-CONVENTION FROM SNMPv2-TC;
ipsecIsakmpIkeDoiTC MODULE-IDENTITY
LAST-UPDATED "0107201800Z"
ORGANIZATION "Intel"
CONTACT-INFO "John Shriver
Intel Corporation
28 Crosby Drive
Bedford, MA 01730
Phone:
+1-781-687-1329
E-mail:
John.Shriver@intel.com"
DESCRIPTION "The MIB module which defines the textual conventions
used in IPsec MIBs. This includes Internet DOI
numbers defined in RFC 2407, ISAKMP numbers defined
in RFC 2408, and IKE numbers defined in RFC 2409.
These Textual Conventions are defined in a seperate
MIB module since they are protocol numbers managed
by the IANA. Revision control after publication
will be under the authority of the IANA."
REVISION "9902181705Z"
DESCRIPTION "Added IsakmpDOI TEXTUAL-CONVENTION."
REVISION "9903051545Z"
DESCRIPTION "Changed CONTACT-INFO."
REVISION "9907132145Z"
DESCRIPTION "Put in real experimental branch number for module."
REVISION "9910051705Z"
DESCRIPTION "Added exchange types, tracked IKE standard. Split
IkeNotifyMessageType off of IsakmpNotifyMessageType."
REVISION "9910151950Z"
DESCRIPTION "Removed stray comma in IsakmpNotifyMessageType."
REVISION "9911232135Z"
IPsec Working Group [Page 4]
Internet Draft IPsec DOI Textual Conventions MIB October 2001
DESCRIPTION "Consistent capitalization of IPsec."
REVISION "0011071445Z"
DESCRIPTION "Catch up with IANA assignments, remove any I-D
references."
REVISION "0104162045Z"
DESCRIPTION "Better phrasing in a few DESCRIPTIONs."
REVISION "0107201800Z"
DESCRIPTION "Use more appropriate definitions for 0 values,
where MIBs use them to represent none."
-- replace xxx in next line before release, uncomment before release
-- ::= { mib-2 xxx }
-- delete next line before release
::= { experimental 100 }
-- The first group of textual conventions are based on definitions
-- in the IPsec DOI, RFC 2407.
IpsecDoiSituation ::= TEXTUAL-CONVENTION
DISPLAY-HINT "x"
STATUS current
DESCRIPTION "The IPsec DOI Situation provides information that
can be used by the responder to make a policy
determination about how to process the incoming
Security Association request.
It is a four (4) octet bitmask, with the following
values:
sitIdentityOnly 0x01
sitSecrecy 0x02
sitIntegrity 0x04
The upper two bits (0x80000000 and 0x40000000) are
reserved for private use amongst cooperating
systems."
REFERENCE "RFC 2407 sections 4.2 and 6.2"
SYNTAX Unsigned32 (0..4294967295)
-- The syntax is not BITS, because we want the representation
-- to be the same here as it is in the ISAKMP/IKE protocols.
IpsecDoiSecProtocolId ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION "These are the IPsec DOI values for the Protocol-Id
field in an ISAKMP Proposal Payload, and in all
IPsec Working Group [Page 5]
Internet Draft IPsec DOI Textual Conventions MIB October 2001
Notification Payloads.
They are also used as the Protocol-ID In the
Notification Payload and the Delete Payload.
The values 249-255 are reserved for private use
amongst cooperating systems."
REFERENCE "RFC 2407 section 4.4.1"
SYNTAX INTEGER {
reserved(0), -- reserved in DOI
protoIsakmp(1), -- message protection
-- required during Phase I
-- of the IKE protocol
protoIpsecAh(2), -- IP packet authentication
-- via Authentication Header
protoIpsecEsp(3), -- IP packet confidentiality
-- via Encapsulating
-- Security Payload
protoIpcomp(4) -- IP payload compression
}
IpsecDoiTransformIdent ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION "The values of the IPsec DOI ISAKMP Transform
Identifier which identify a key exchange protocol
to be used for the negotiation. It is used in the
Transform-Id field of an IKE Phase I Transform
Payload.
The values 249-255 are reserved for private use
amongst cooperating systems."
REFERENCE "RFC 2407 sections 4.4.2 and 6.3"
SYNTAX INTEGER {
reserved(0), -- reserved in DOI
keyIke(1) -- the hybrid ISAKMP/Oakley
-- Diffie-Hellman key
-- exchange
}
IpsecDoiAhTransform ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION "The values of the IPsec DOI AH Transform Identifier
which identify a particular algorithm to be
used to provide integrity protection for AH. It is
used in the Tranform-ID field of a ISAKMP Transform
IPsec Working Group [Page 6]
Internet Draft IPsec DOI Textual Conventions MIB October 2001
Payload for the IPsec DOI, when the Protocol-Id of
the associated Proposal Payload is 2 (AH).
The values 249-255 are reserved for private use
amongst cooperating systems."
REFERENCE "RFC 2407 sections 4.4.3 and 6.4,
IANA,
RFC 2857"
SYNTAX INTEGER {
reserved(0), -- reserved in DOI
reserved1(1), -- reserved
ahMd5(2), -- generic AH transform
-- using MD5
ahSha(3), -- generic AH transform
-- using SHA-1
ahDes(4), -- generic AH transform
-- using DES
ahSha256(5), -- generic AH transform
-- using SHA-256
ahSha384(6), -- generic AH transform
-- using SHA-384
ahSha512(7), -- generic AH transform
-- using SHA-512
ahRipemd(8) -- generic AH transform
-- using HMAC-RIPEMD-160-96
-- RFC 2857
}
IpsecDoiEspTransform ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION "The values of the IPsec DOI ESP Transform Identifier
which identify a particular algorithm to be used to
provide secrecy protection for ESP. It is used in
the Tranform-ID field of a ISAKMP Transform Payload
for the IPsec DOI, when the Protocol-Id of the
associated Proposal Payload is 2 (AH), 3 (ESP),
and 4 (IPCOMP).
The values 249-255 are reserved for private use
amongst cooperating systems."
REFERENCE "RFC 2407 sections 4.4.4 and 6.5,
IANA"
SYNTAX INTEGER {
none(0), -- reserved in DOI, used
-- in MIBs to reflect no
-- encryption used
IPsec Working Group [Page 7]
Internet Draft IPsec DOI Textual Conventions MIB October 2001
espDesIv64(1), -- DES-CBC transform defined
-- in RFC 1827 and RFC 1829
-- using a 64-bit IV
espDes(2), -- generic DES transform
-- using DES-CBC
esp3Des(3), -- generic triple-DES
-- transform
espRc5(4), -- RC5 transform
espIdea(5), -- IDEA transform
espCast(6), -- CAST transform
espBlowfish(7), -- BLOWFISH transform
esp3Idea(8), -- reserved for triple-IDEA
espDesIv32(9), -- DES-CBC transform defined
-- in RFC 1827 and RFC 1829
-- using a 32-bit IV
espRc4(10), -- reserved for RC4
espNull(11), -- no confidentiality
-- provided by ESP
espAes(12) -- NIST AES transform
}
IpsecDoiAuthAlgorithm ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION "The ESP Authentication Algorithm used in the IPsec
DOI as a SA Attributes definition in the Transform
Payload of Phase II of an IKE negotiation. This
set of values defines the AH authentication
algorithm, when the associated Proposal Payload has
a Protocol-ID of 2 (AH). This set of values
defines the ESP authentication algorithm, when the
associated Proposal Payload has a Protocol-ID
of 3 (ESP).
Unused values <= 61439 are reserved to IANA.
Values 61440-65535 are for private use.
In a MIB, a value of 0 indicates that ESP
has been negotiated without authentication."
REFERENCE "RFC 2407 section 4.5,
RFC 2407 section 4.4.3.1,
RFC 1826,
IANA,
RFC 2857"
SYNTAX INTEGER {
none(0), -- reserved in DOI, used
IPsec Working Group [Page 8]
Internet Draft IPsec DOI Textual Conventions MIB October 2001
-- in MIBs to reflect no
-- encryption used
hmacMd5(1), -- hashed MAC using MD5
hmacSha(2), -- hashed MAC using SHA-1
desMac(3), -- DES MAC
kpdk(4), -- RFC 1826
-- Key/Pad/Data/Key
hmacSha256(5), -- hashed MAC using SHA-256
hmacSha384(6), -- hashed MAC using SHA-384
hmacSha512(7), -- hashed MAC using SHA-512
hamcRipemd(8) -- hashed MAC using
-- RIPEMD-160-96
}
IpsecDoiIpcompTransform ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION "The IPsec DOI IPCOMP Transform Identifier is an
8-bit value which identifies a particular algorithm
to be used to provide IP-level compression before
ESP. It is used in the Tranform-ID field of a ISAKMP
Transform Payload for the IPsec DOI, when the
Protocol-Id of the associated Proposal Payload
is 4 (IPCOMP).
The values 1-47 are reserved for algorithms for which
an RFC has been approved for publication.
The values 48-63 are reserved for private use amongst
cooperating systems.
The values 64-255 are reserved for future expansion."
REFERENCE "RFC 2407 sections 4.4.5 and 6.6"
SYNTAX INTEGER {
reserved(0), -- reserved in DOI
ipcompOui(1), -- proprietary compression
-- transform
ipcompDeflate(2), -- "zlib" deflate algorithm
ipcompLzs(3) -- Stac Electronics LZS
}
IpsecDoiEncapsulationMode ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION "The Encapsulation Mode used as an IPsec DOI
SA Attributes definition in the Transform Payload
of a Phase II IKE negotiation. This set of
IPsec Working Group [Page 9]
Internet Draft IPsec DOI Textual Conventions MIB October 2001
values defines encapsulation modes used for AH,
ESP, and IPCOMP when the associated Proposal Payload
has a Protocol-ID of 3 (ESP).
Unused values <= 61439 are reserved to IANA.
Values 61440-65535 are for private use."
SYNTAX INTEGER {
reserved(0), -- reserved in DOI
tunnel(1),
transport(2)
}
IpsecDoiIdentType ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION "The IPsec DOI Identification Type is an 8-bit value
which is used in the ID Type field as a discriminant
for interpretation of the variable-length
Identification Payload.
The values 249-255 are reserved for private use
amongst cooperating systems."
REFERENCE "RFC 2407 sections 4.4.5, 4.6.2.1, and 6.9"
SYNTAX INTEGER {
reserved(0), -- reserved in DOI
idIpv4Addr(1), -- a single four (4) octet
-- IPv4 address
idFqdn(2), -- fully-qualified domain
-- name string
idUserFqdn(3), -- fully-qualified username
-- string
idIpv4AddrSubnet(4),
-- a range of IPv4 addresses,
-- represented by two
-- four (4) octet values,
-- where the first is an
-- address and the second
-- is a mask
idIpv6Addr(5), -- a single sixteen (16)
-- octet IPv6 address
idIpv6AddrSubnet(6),
-- a range of IPv6 addresses,
-- represented by two
-- sixteen (16) octet values,
-- where the first is an
-- address and the second
IPsec Working Group [Page 10]
Internet Draft IPsec DOI Textual Conventions MIB October 2001
-- is a mask
idIpv4AddrRange(7), -- a range of IPv4 addresses,
-- represented by two
-- four (4) octet values,
-- where the first is the
-- beginning IPv4 address
-- and the second is the
-- ending IPv4 address
idIpv6AddrRange(8), -- a range of IPv6 addresses,
-- represented by two
-- sixteen (16) octet values,
-- where the first is the
-- beginning IPv6 address
-- and the second is the
-- ending IPv6 address
idDerAsn1Dn(9), -- the binary DER encoding of
-- ASN1 X.500
-- DistinguishedName
idDerAsn1Gn(10), -- the binary DER encoding of
-- ASN1 X.500 GeneralName
idKeyId(11) -- opaque byte stream which
-- may be used to pass
-- vendor-specific
-- information
}
-- The second group of textual conventions are based on defintions
-- the ISAKMP protocol, RFC 2408.
IsakmpDOI ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION "These are the domain of interpretation values for
the ISAKMP Protocol. They are a 32-bit value
used in the Domain of Interpretation field of the
Security Association Payload.
Unused values <= 4294967295 are reserved to
the IANA."
REFERENCE "RFC 2048 section 3.4."
SYNTAX INTEGER {
isakmp(0), -- generic ISAKMP SA in
-- Phase 1, which can be
-- used for any protocol
-- in Phase 2
ipsecDOI(1) -- the IPsec DOI as
-- specified in RFC 2407
IPsec Working Group [Page 11]
Internet Draft IPsec DOI Textual Conventions MIB October 2001
}
IsakmpCertificateEncoding ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION "These are the values for the types of
certificate-related information contained in the
Certificate Data field of a Certificate Payload.
They are used in the Cert Encoding field of the
Certificate Payload.
Values 11-255 are reserved."
REFERENCE "RFC 2408 section 3.9"
SYNTAX INTEGER {
pkcs7(1), -- PKCS #7 wrapped
-- X.509 certificate
pgp(2), -- PGP Certificate
dnsSignedKey(3), -- DNS Signed Key
x509Signature(4), -- X.509 Certificate:
-- Signature
x509KeyExchange(5), -- X.509 Certificate:
-- Key Exchange
kerberosTokens(6), -- Kerberos Tokens
crl(7), -- Certificate Revocation
-- List (CRL)
arl(8), -- Authority Revocation
-- List (ARL)
spki(9), -- SPKI Certificate
x509Attribute(10) -- X.509 Certificate:
-- Attribute
}
IsakmpExchangeType ::= TEXTUAL-CONVENTION
--
-- When revising IsakmpExchangeType, consider revising
-- IkeExchangeType as well.
--
DISPLAY-HINT "d"
STATUS current
DESCRIPTION "These are the values used for the exchange types in
the ISAKMP header.
Values up to 31 are reserved for future
DOI-independent assignment for ISAKMP.
The values 240-255 are reserved for private use
amongst cooperating systems."
IPsec Working Group [Page 12]
Internet Draft IPsec DOI Textual Conventions MIB October 2001
REFERENCE "RFC 2408 section 3.1"
SYNTAX INTEGER {
reserved(0),
base(1), -- base mode
identityProtect(2), -- identity protection
authOnly(3), -- authentication only
aggressive(4), -- aggressive mode
informational(5) -- informational
}
IsakmpNotifyMessageType ::= TEXTUAL-CONVENTION
--
-- If you change this, you probably want to
-- change IkeNotifyMessageType.
--
DISPLAY-HINT "d"
STATUS current
DESCRIPTION "These are the values for the types of notification
messages. They are used as the Notify Message Type
field in the Notification Payload.
This textual convention merges the types
for error types (in the range 1-16386) and for
notification types (in the range 16384-65535).
The values 16001-16383 are reserved for private use
as error types amongst cooperating systems.
The values 24576-32767 are reserved for use in
each DOI. Each DOI should have a clone of this
textual convention adding local values.
The values 32768-40958 are reserved for private use
as notification types amongst cooperating systems."
REFERENCE "RFC 2408 section 3.14.1"
SYNTAX INTEGER {
-- Values defined for errors in ISAKMP
--
reserved(0), -- reserved in DOI
invalidPayloadType(1),
doiNotSupported(2),
situationNotSupported(3),
invalidCookie(4),
invalidMajorVersion(5),
invalidMinorVersion(6),
invalidExchangeType(7),
IPsec Working Group [Page 13]
Internet Draft IPsec DOI Textual Conventions MIB October 2001
invalidFlags(8),
invalidMessageId(9),
invalidProtocolId(10),
invalidSpi(11),
invalidTransformId(12),
attributesNotSupported(13),
noProposalChosen(14),
badProposalSyntax(15),
payloadMalformed(16),
invalidKeyInformation(17),
invalidIdInformation(18),
invalidCertEncoding(19),
invalidCertificate(20),
certTypeUnsupported(21),
invalidCertAuthority(22),
invalidHashInformation(23),
authenticationFailed(24),
invalidSignature(25),
addressNotification(26),
notifySaLifetime(27),
certificateUnavailable(28),
unsupportedExchangeType(29),
unequalPayloadLengths(30)
-- values defined for errors in IPsec DOI
-- (none)
-- values defined for notification in ISAKMP
-- (none)
-- values defined for notification in
-- each DOI (clone this TC)
}
-- The third group of textual conventions are based on defintions
-- the IKE key exchange protocol, RFC 2409.
IkeExchangeType ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION "These are the values used for the exchange types in
the ISAKMP header.
The values 32-239 are DOI-specific, these values are
for the IPsec DOI used by IKE.
IPsec Working Group [Page 14]
Internet Draft IPsec DOI Textual Conventions MIB October 2001
The values 240-255 are reserved for private use
amongst cooperating systems."
REFERENCE "RFC 2409 Appendix A"
SYNTAX INTEGER {
reserved(0),
base(1), -- base mode
mainMode(2), -- main mode
authOnly(3), -- authentication only
aggressive(4), -- aggressive mode
informational(5), -- informational
quickMode(32), -- quick mode
newGroupMode(33) -- new group mode
}
IkeEncryptionAlgorithm ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION "Values for encryption algorithms negotiated
for the ISAKMP SA by IKE in Phase I. These are
values for SA Attrbute type Encryption
Algorithm (1).
Unused values <= 65000 are reserved to IANA.
Values 65001-65535 are for private use among
mutually consenting parties."
REFERENCE "RFC 2409 appendix A,
IANA"
SYNTAX INTEGER {
reserved(0), -- reserved in IKE
desCbc(1), -- RFC 2405
ideaCbc(2),
blowfishCbc(3),
rc5R16B64Cbc(4), -- RC5 R16 B64 CBC
tripleDesCbc(5), -- 3DES CBC
castCbc(6),
aesCbc(7)
}
IkeHashAlgorithm ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION "Values for hash algorithms negotiated
for the ISAKMP SA by IKE in Phase I. These are
values for SA Attrbute type Hash Algorithm (2).
Unused values <= 65000 are reserved to IANA.
IPsec Working Group [Page 15]
Internet Draft IPsec DOI Textual Conventions MIB October 2001
Values 65001-65535 are for private use among
mutually consenting parties."
REFERENCE "RFC 2409 appendix A,
IANA"
SYNTAX INTEGER {
reserved(0), -- reserved in IKE
md5(1), -- RFC 1321
sha(2), -- FIPS 180-1
tiger(3),
sha256(4),
sha384(5),
sha512(6)
}
IkeAuthMethod ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION "Values for authentication methods negotiated
for the ISAKMP SA by IKE in Phase I. These are
values for SA Attrbute type Authentication
Method (3).
Unused values <= 65000 are reserved to IANA.
Values 65001-65535 are for private use among
mutually consenting parties."
REFERENCE "RFC 2409 appendix A,
IANA"
SYNTAX INTEGER {
reserved(0), -- reserved in IKE
preSharedKey(1),
dssSignatures(2),
rsaSignatures(3),
encryptionWithRsa(4),
revisedEncryptionWithRsa(5),
encryptionWithElGamal(6),
revisedEncryptionWithElGamal(7),
ecdsaSignatures(8)
}
IkeGroupDescription ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION "Values for Oakley key computation groups for
Diffie-Hellman exchange negotiated for the ISAKMP
SA by IKE in Phase I. They are also used in Phase II
when perfect forward secrecy is in use. These are
IPsec Working Group [Page 16]
Internet Draft IPsec DOI Textual Conventions MIB October 2001
values for SA Attrbute type Group Description (4).
Unused values <= 32767 are reserved to IANA.
Values 32768-65535 are for private use among
mutually consenting parties."
REFERENCE "RFC 2409 appendix A,
IANA"
SYNTAX INTEGER {
none(0), -- reserved in IKE, used
-- in MIBs to reflect that
-- none of the predefined
-- groups are used
modp768(1), -- default 768-bit MODP group
modp1024(2), -- alternate 1024-bit MODP
-- group
ec2nGF155(3), -- EC2N group on Galois
-- Field GF[2^155]
ec2nGF185(4), -- EC2N group on Galois
-- Field GF[2^185]
ec2nGF163Random(6), -- EC2N group on Galois
-- Field GF[2^163],
-- random seed
ec2nGF163Koblitz(7),
-- EC2N group on Galois
-- Field GF[2^163],
-- Koblitz curve
ec2nGF283Random(8), -- EC2N group on Galois
-- Field GF[2^283],
-- random seed
ec2nGF283Koblitz(9),
-- EC2N group on Galois
-- Field GF[2^283],
-- Koblitz curve
ec2nGF409Random(10),
-- EC2N group on Galois
-- Field GF[2^409],
-- random seed
ec2nGF409Koblitz(11),
-- EC2N group on Galois
-- Field GF[2^409],
-- Koblitz curve
ec2nGF571Random(12),
-- EC2N group on Galois
-- Field GF[2^571],
-- random seed
ec2nGF571Koblitz(13)
IPsec Working Group [Page 17]
Internet Draft IPsec DOI Textual Conventions MIB October 2001
-- EC2N group on Galois
-- Field GF[2^571],
-- Koblitz curve
}
IkeGroupType ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION "Values for Oakley key computation group types
negotiated for the ISAKMP SA by IKE in Phase I.
They are also used in Phase II when perfect forward
secrecy is in use. These are values for SA Attribute
type Group Type (5)."
REFERENCE "RFC 2409 appendix A"
SYNTAX INTEGER {
reserved(0), -- reserved in IKE
modp(1), -- modular eponentiation
-- group
ecp(2), -- elliptic curve group over
-- Galois Field GF[P]
ec2n(3) -- elliptic curve group over
-- Galois Field GF[2^N]
}
IkePrf ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION "Values for Pseudo-Random Functions used with
with the hash algorithm negotiated for the ISAKMP SA
by IKE in Phase I. There are currently no
pseudo-random functions defined, the default HMAC is
always used. These are values for SA Attribute type
PRF (13).
Unused values <= 65000 are reserved to IANA.
Values 65001-65535 are for private use among
mutually consenting parties."
REFERENCE "RFC 2409 appendix A"
SYNTAX Unsigned32 (0..65535)
IkeNotifyMessageType ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION "These are the values for the types of notification
messages. They are used as the Notify Message Type
IPsec Working Group [Page 18]
Internet Draft IPsec DOI Textual Conventions MIB October 2001
field in the Notification Payload.
This textual convention merges the types
for error types (in the range 1-16386) and for
notification types (in the range 16384-65535).
This textual convention is a merge of values
defined by ISAKMP with the additional values
defined in the IPsec DOI.
The values 16001-16383 are reserved for private use
as error types amongst cooperating systems.
The values 32001-32767 are reserved for private use
as notification types amongst cooperating systems."
REFERENCE "RFC 2408 section 3.14.1 and RFC 2407 sections 4.6.3
and 6.10"
SYNTAX INTEGER {
-- Values defined for errors in ISAKMP
--
unknown(0), -- reserved in DOI
-- used for unknown in MIBs
invalidPayloadType(1),
doiNotSupported(2),
situationNotSupported(3),
invalidCookie(4),
invalidMajorVersion(5),
invalidMinorVersion(6),
invalidExchangeType(7),
invalidFlags(8),
invalidMessageId(9),
invalidProtocolId(10),
invalidSpi(11),
invalidTransformId(12),
attributesNotSupported(13),
noProposalChosen(14),
badProposalSyntax(15),
payloadMalformed(16),
invalidKeyInformation(17),
invalidIdInformation(18),
invalidCertEncoding(19),
invalidCertificate(20),
certTypeUnsupported(21),
invalidCertAuthority(22),
invalidHashInformation(23),
authenticationFailed(24),
IPsec Working Group [Page 19]
Internet Draft IPsec DOI Textual Conventions MIB October 2001
invalidSignature(25),
addressNotification(26),
notifySaLifetime(27),
certificateUnavailable(28),
unsupportedExchangeType(29),
unequalPayloadLengths(30),
-- values defined for errors in IPsec DOI
-- (none)
-- values defined for notification in ISAKMP
-- (none)
-- values defined for notification in IPsec
-- DOI
responderLifetime(24576),
-- used to communicate IPsec
-- SA lifetime chosen by the
-- responder
replayStatus(24577),
-- used for positive
-- confirmation of the
-- responder's election on
-- whether or not he is to
-- perform anti-replay
-- detection
initialContact(24578)
-- used when one side wishes
-- to inform the other that
-- this is the first SA being
-- established with the
-- remote system
}
END
5. Security Considerations
Since this MIB defines only textual conventions, there are no
security considerations. Security considerations exist only when
managed objects are defined with these textual conventions.
IPsec Working Group [Page 20]
Internet Draft IPsec DOI Textual Conventions MIB October 2001
6. IANA Considerations
This document is the MIB definitions corresponding to a group of
"magic numberes" that are maintained by the IANA. The IANA will
maintain the MIB in this document as they assign new values of these
magic numbers.
This MIB will be maintained in the same manner as the IANAifType-MIB.
7. Acknowledgements
Thanks are extended to Tim Jenkins for modifying his MIBs to use
these textual conventions.
8. Revision History
This section will be removed before publication.
February 3, 1999. Initial release as draft-shriver-doi-tc-mib-
00.txt, due to issues as to whether the MIB was an IPsec or IPsecond
work item.
March 22, 1999. Released as draft-ietf-ipsec-doi-tc-mib-00.txt.
Added IsakmpDOI textual convention.
October 13, 1999. Use real number in experimental branch. Added
IsakmpExchangeType and IkeExchangeType. Split IkeNotifyMessageType
off of IsakmpNotifyMessageType, and removed IPsec DOI values from the
latter. Corrected latest values of IkeAuthMethod, there had been
some "number grabbing" in Internet-Drafts, now tracking the IKE
Internet-Draft. Cleaned up references.
October 15, 1999. Removed stray comma in MIB.
June 13, 2000. Enforced consistent capitalization of IPsec.
November 22, 2000. Updated with the recent IANA assignments,
particularly for AES, also from RFC 2857. Removed any numbers
assigned only in the IKE Internet-Draft, since those cannot go in an
RFC, and this is going out first.
October 3, 2001. Some changes in descriptions from readers'
comments. For those variables defined as enumerations, where the
protocol defines the value 0 as reserved, but the MIBs use the value
0 to indicate none, change the naming to none, and properly document
the dual meaning.
IPsec Working Group [Page 21]
Internet Draft IPsec DOI Textual Conventions MIB October 2001
9. References
[IKE] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)",
RFC 2409, November 1998
[IPDOI] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998
[ISAKMP] Maughan, D., Schertler, M., Schneider, M., and Turner, J.,
"Internet Security Association and Key Management Protocol
(ISAKMP)", RFC 2408, November 1998
[SECARCH] Kent, S., Atkinson, R., "Security Architecture for the
Internet Protocol", RFC 2401, November 1998
[1155] Rose, M., and K. McCloghrie, "Structure and Identification
of Management Information for TCP/IP-based Internets",
RFC 1155, May 1990
[1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
Network Management Protocol", RFC 1157, May 1990.
[1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", RFC
1212, March 1991
[1215] M. Rose, "A Convention for Defining Traps for use with the
SNMP", RFC 1215, March 1991
[1901] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M.,
and S. Waldbusser, "Introduction to Community-based
SNMPv2", RFC 1901, January 1996.
[1905] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M.,
and S. Waldbusser, "Protocol Operations for Version 2 of
the Simple Network Management Protocol (SNMPv2)", RFC 1905,
January 1996.
[1906] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M.,
and S. Waldbusser, "Transport Mappings for Version 2 of the
Simple Network Management Protocol (SNMPv2)", RFC 1906,
January 1996.
[2570] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction to Version 3 of the Internet-standard Network
Management Framework", RFC 2570, April 1999
IPsec Working Group [Page 22]
Internet Draft IPsec DOI Textual Conventions MIB October 2001
[2571] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing SNMP Management Frameworks",
RFC 2571, April 1999
[2572] Case, J., Harrington D., Presuhn R., and B. Wijnen,
"Message Processing and Dispatching for the Simple Network
Management Protocol (SNMP)", RFC 2572, April 1999
[2573] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications",
RFC 2573, April 1999
[2574] Blumenthal, U., and B. Wijnen, "User-based Security Model
(USM) for version 3 of the Simple Network Management
Protocol (SNMPv3)", RFC 2574, April 1999
[2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based
Access Control Model (VACM) for the Simple Network
Management Protocol (SNMP)", RFC 2575, April 1999
[2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M., and S. Waldbusser, "Structure of Management
Information Version 2 (SMIv2)", STD 58, RFC 2578, April
1999
[2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M., and S. Waldbusser, "Textual Conventions for
SMIv2", STD 58, RFC 2579, April 1999
[2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M., and S. Waldbusser, "Conformance Statements for
SMIv2", STD 58, RFC 2580, April 1999
10. Author's Address
John Shriver
Intel Corporation
28 Crosby Drive
Bedford, MA 01730
Phone: +1-781-687-1329
EMail: John.Shriver@intel.com
IPsec Working Group [Page 23]
