Skip to main content

Internet Security Glossary, Version 2
draft-shirey-secgloss-v2-08

Revision differences

Document history

Date Rev. By Action
2012-08-22
08 (System) post-migration administrative database adjustment to the Abstain position for Dan Romascanu
2007-08-29
08 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2007-08-29
08 Amy Vezza [Note]: 'RFC 4949<br>FYI 0036' added by Amy Vezza
2007-08-20
08 (System) RFC published
2006-11-15
08 (System) New version available: draft-shirey-secgloss-v2-08.txt
2006-11-13
08 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2006-10-02
08 Amy Vezza IESG state changed to Approved-announcement sent
2006-10-02
08 Amy Vezza IESG has approved the document
2006-10-02
08 Amy Vezza Closed "Approve" ballot
2006-09-29
08 (System) Removed from agenda for telechat - 2006-09-28
2006-09-28
08 Amy Vezza State Changes to Approved-announcement to be sent from IESG Evaluation by Amy Vezza
2006-09-28
08 Dan Romascanu
[Ballot comment]
1. 'community string' article - This article is mis-representing what community strings were meant to be in SNMPv1 and SNMPv2. None of RFC …
[Ballot comment]
1. 'community string' article - This article is mis-representing what community strings were meant to be in SNMPv1 and SNMPv2. None of RFC 1157 or RFC 1901 referenced here defines community string as a 'cleartext password'. I would suggest that these references be consulted for a proper definition of the term.

2. 'Simple Network Management Protocol' article - SNMP is not 'TCP-based'. Also it is no longer solely defined to pass information between managers and agents

3. The 'Standards for Interoperable LAN/MAN Security (SILS)' article mentions IEEE 802.10 which was deprecated by the IEEE, but ignores the more recent work on security in IEEE 802.1 like IEEE 802.1X and IEEE 802.1AE

4. 'IEEE 802.10' article - The IEEE 802.10 Working Group was shut down a few years ago, while a Security Task Force was formed since 2002 in IEEE 802.1 as has now taken over principal responsibilities related to security standards in the IEEE 802. I suggest taking out this article or mentioning that 802.10 is historical and include an article about the IEEE 802.1 security task force

5. 'WEP' article - I find strange for a document published in 2006 or 2007 to dedicate an article to WEP without any discussion about its vulnerabilities, and ignore IEEE 802.11i
2006-09-28
08 Dan Romascanu [Ballot Position Update] Position for Dan Romascanu has been changed to Abstain from Discuss by Dan Romascanu
2006-09-28
08 Jari Arkko
[Ballot comment]
> (I) A extension framework for PPP that supports multiple, optional
> authentication mechanisms, including cleartext passwords,
> challenge-response, and arbitrary dialog sequences. …
[Ballot comment]
> (I) A extension framework for PPP that supports multiple, optional
> authentication mechanisms, including cleartext passwords,
> challenge-response, and arbitrary dialog sequences. [R3748]

Please rewrite as "An authentication framework that supports different
authentication methods, including cleartext passwords,
challenge-response, certificates, shared secrets, SIM cards, and so
on.", or something to that effect. As you note below it is not merely
for PPP. And the EAP term is "methods", not "mechanisms". Finally,
the set of methods would be good to update.

> $ IKE
>  (I) See: IPsec Key Exchange.

I think you mean Internet Key Exchange.

> $ Remote Authentication Dial-In User Service (RADIUS)

Consider adding a definition for Diameter as well, and a generic
term for AAA.

> $ Internet Key Exchange (IKE)
>  (I) An Internet, IPsec, key-establishment protocol [R4306] for
>  putting in place authenticated keying material (a) for use with
>  ISAKMP and (b) for other security associations, such as in AH and
>  ESP.
>
>  Tutorial: IKE is based on three earlier protocol designs: ISAKMP,
>  OAKLEY, and SKEME.

Question: is all of this still valid with IKEv2?

> Tutorial: If IP were used in an OSIRM stack, IP would be placed at
> the top of Layer 3, above other Layer 3 protocols in the stack.
>
> In any IPS stack, IP is always present in the Internet Layer and
> is always placed at the top of that layer, on top of any other
> protocols that are used in that layer. In some sense, IP is the
> only protocol specified for the IPS Internet Layer; other
> protocols used there, such as AH and ESP, are just IP variations.

My head hurts when I try to understand this definition.
What would the other protocols in Internet Layer be?
If there are such protocols, e.g., AH/ESP/HIP/SHIM/MIP/etc,
they are not necessarily under IP.

> 2. Envy: Poor Data Link is always starved for attention. (With
>    Asynchronous Transfer Mode, maybe now it is feeling less
>    neglected.)

Perhaps this should be written as

      2. Envy: Poor Data Link is always starved for attention. (Back
        in the times of the Asynchronous Transfer Mode, it was
        feeling a lot less neglected.)
2006-09-28
08 Jari Arkko [Ballot Position Update] Position for Jari Arkko has been changed to No Objection from Discuss by Jari Arkko
2006-09-28
08 Jari Arkko [Ballot discuss]
2006-09-28
08 Bill Fenner [Ballot Position Update] Position for Bill Fenner has been changed to Abstain from No Objection by Bill Fenner
2006-09-28
08 Jari Arkko
[Ballot discuss]
> (I) A extension framework for PPP that supports multiple, optional
> authentication mechanisms, including cleartext passwords,
> challenge-response, and arbitrary dialog sequences. …
[Ballot discuss]
> (I) A extension framework for PPP that supports multiple, optional
> authentication mechanisms, including cleartext passwords,
> challenge-response, and arbitrary dialog sequences. [R3748]

Please rewrite as "An authentication framework that supports different
authentication methods, including cleartext passwords,
challenge-response, certificates, shared secrets, SIM cards, and so
on.", or something to that effect. As you note below it is not merely
for PPP. And the EAP term is "methods", not "mechanisms". Finally,
the set of methods would be good to update.

> $ IKE
>  (I) See: IPsec Key Exchange.

I think you mean Internet Key Exchange.

COMMENT-only part:

> $ Remote Authentication Dial-In User Service (RADIUS)

Consider adding a definition for Diameter as well, and a generic
term for AAA.

> $ Internet Key Exchange (IKE)
>  (I) An Internet, IPsec, key-establishment protocol [R4306] for
>  putting in place authenticated keying material (a) for use with
>  ISAKMP and (b) for other security associations, such as in AH and
>  ESP.
>
>  Tutorial: IKE is based on three earlier protocol designs: ISAKMP,
>  OAKLEY, and SKEME.

Question: is all of this still valid with IKEv2?

> Tutorial: If IP were used in an OSIRM stack, IP would be placed at
> the top of Layer 3, above other Layer 3 protocols in the stack.
>
> In any IPS stack, IP is always present in the Internet Layer and
> is always placed at the top of that layer, on top of any other
> protocols that are used in that layer. In some sense, IP is the
> only protocol specified for the IPS Internet Layer; other
> protocols used there, such as AH and ESP, are just IP variations.

My head hurts when I try to understand this definition.
What would the other protocols in Internet Layer be?
If there are such protocols, e.g., AH/ESP/HIP/SHIM/MIP/etc,
they are not necessarily under IP.

> 2. Envy: Poor Data Link is always starved for attention. (With
>    Asynchronous Transfer Mode, maybe now it is feeling less
>    neglected.)

Perhaps this should be written as

      2. Envy: Poor Data Link is always starved for attention. (Back
        in the times of the Asynchronous Transfer Mode, it was
        feeling a lot less neglected.)
2006-09-28
08 Lisa Dusseault [Ballot Position Update] New position, Abstain, has been recorded by Lisa Dusseault
2006-09-28
08 Jari Arkko
[Ballot discuss]
> (I) A extension framework for PPP that supports multiple, optional
> authentication mechanisms, including cleartext passwords,
> challenge-response, and arbitrary dialog sequences. …
[Ballot discuss]
> (I) A extension framework for PPP that supports multiple, optional
> authentication mechanisms, including cleartext passwords,
> challenge-response, and arbitrary dialog sequences. [R3748]

Please rewrite as "An authentication framework that supports different
authentication methods, including cleartext passwords,
challenge-response, certificates, shared secrets, SIM cards, and so
on.", or something to that effect. As you note below it is not merely
for PPP. And the EAP term is "methods", not "mechanisms". Finally,
the set of methods would be good to update.

> $ IKE
>  (I) See: IPsec Key Exchange.

I think you mean Internet Key Exchange.

COMMENT-only part:

> $ Remote Authentication Dial-In User Service (RADIUS)

Consider adding a definition for Diameter as well, and a generic
term for AAA.

> $ Internet Key Exchange (IKE)
>  (I) An Internet, IPsec, key-establishment protocol [R4306] for
>  putting in place authenticated keying material (a) for use with
>  ISAKMP and (b) for other security associations, such as in AH and
>  ESP.
>
>  Tutorial: IKE is based on three earlier protocol designs: ISAKMP,
>  OAKLEY, and SKEME.

Question: is all of this still valid with IKEv2?

> Tutorial: If IP were used in an OSIRM stack, IP would be placed at
> the top of Layer 3, above other Layer 3 protocols in the stack.
>
> In any IPS stack, IP is always present in the Internet Layer and
> is always placed at the top of that layer, on top of any other
> protocols that are used in that layer. In some sense, IP is the
> only protocol specified for the IPS Internet Layer; other
> protocols used there, such as AH and ESP, are just IP variations.

My head hurts when I try to understand this definition.
What would the other protocols in Internet Layer be?
If there are such protocols, e.g., AH/ESP/HIP/SHIM/MIP/etc,
they are not necessarily under IP.
2006-09-28
08 Jari Arkko [Ballot Position Update] New position, Discuss, has been recorded by Jari Arkko
2006-09-28
08 Magnus Westerlund [Ballot comment]
I am somewhat worried about the less than correct description of some words, like TCP. Lets discuss this.
2006-09-28
08 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund
2006-09-27
08 Sam Hartman
[Ballot comment]
I appreciate that a lot of work has gone into this draft and into the
security glossary.  However there is a lot left …
[Ballot comment]
I appreciate that a lot of work has gone into this draft and into the
security glossary.  However there is a lot left in the glossary that
is the author's personal opinion.  We found a number of instances
where the author was trying to use this glossary to establish
normative meanings for words based on his belief of how those words
should be used--sometimes in direct conflict with common practice.  I
think RFC 2828 is very useful, but I question whether the added length
of this document and the cases in which definitions reflect the
author's bias rather than the actual use of terms will enhance or
reduce the utility of this document over RFC 2828.

My recommendation is that if the rfc editor chooses to publish this
document, that it not obselete RFC 2828 and that the RFC editor make
it quite clear that this is the author's personal opinions about these
terms.

That said, I continue to appreciate the tremendous work that has gone
into this document and RFC 2828.
2006-09-27
08 Sam Hartman [Ballot Position Update] New position, Abstain, has been recorded by Sam Hartman
2006-09-27
08 Bill Fenner
[Ballot comment]
While newtrk's ISD proposal never went anywhere, it was (in my experience) the introduction of the term ISD to the IETF.  This document …
[Ballot comment]
While newtrk's ISD proposal never went anywhere, it was (in my experience) the introduction of the term ISD to the IETF.  This document uses ISD to refer to (as far as I can tell) RFCs; I think doing so will create confusion.
2006-09-27
08 Bill Fenner [Ballot Position Update] New position, No Objection, has been recorded by Bill Fenner
2006-09-27
08 Yoshiko Fong IANA Evaluation Comment:

As described in the IANA Considerations section, we understand this
document to have NO IANA Actions.
2006-09-27
08 Dan Romascanu
[Ballot discuss]
1. 'community string' article - This article is mis-representing what community strings were meant to be in SNMPv1 and SNMPv2. None of RFC …
[Ballot discuss]
1. 'community string' article - This article is mis-representing what community strings were meant to be in SNMPv1 and SNMPv2. None of RFC 1157 or RFC 1901 referenced here defines community string as a 'cleartext password'. I would suggest that these references be consulted for a proper definition of the term.

2. 'Simple Network Management Protocol' article - SNMP is not 'TCP-based'. Also it is no longer solely defined to pass information between managers and agents

3. The 'Standards for Interoperable LAN/MAN Security (SILS)' article mentions IEEE 802.10 which was deprecated by the IEEE, but ignores the more recent work on security in IEEE 802.1 like IEEE 802.1X and IEEE 802.1AE

4. 'IEEE 802.10' article - The IEEE 802.10 Working Group was shut down a few years ago, while a Security Task Force was formed since 2002 in IEEE 802.1 as has now taken over principal responsibilities related to security standards in the IEEE 802. I suggest taking out this article or mentioning that 802.10 is historical and include an article about the IEEE 802.1 security task force

5. 'WEP' article - I find strange for a document published in 2006 or 2007 to dedicate an article to WEP without any discussion about its vulnerabilities, and ignore IEEE 802.11i
2006-09-27
08 Dan Romascanu [Ballot Position Update] New position, Discuss, has been recorded by Dan Romascanu
2006-09-27
08 Lars Eggert [Ballot comment]
2006-09-26
08 Lars Eggert [Ballot comment]
Has a huge list of missing references, uncited references and violates many idnits. Should really be fixed before this hits the RFC Editor.
2006-09-26
08 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert
2006-09-25
08 Russ Housley Placed on agenda for telechat - 2006-09-28 by Russ Housley
2006-09-25
08 Russ Housley State Changes to IESG Evaluation from AD Evaluation by Russ Housley
2006-09-25
08 Russ Housley [Ballot Position Update] New position, Yes, has been recorded for Russ Housley
2006-09-25
08 Russ Housley Ballot has been issued by Russ Housley
2006-09-25
08 Russ Housley Created "Approve" ballot
2006-09-25
08 (System) Ballot writeup text was added
2006-09-25
08 (System) Last call text was added
2006-09-25
08 (System) Ballot approval text was added
2006-09-25
08 Russ Housley State Changes to AD Evaluation from Publication Requested by Russ Housley
2006-09-14
08 Amy Vezza Shepherding AD has been changed to Russ Housley from Brian Carpenter
2006-09-14
08 Dinara Suleymanova Draft Added by Dinara Suleymanova in state Publication Requested
2006-09-10
07 (System) New version available: draft-shirey-secgloss-v2-07.txt
2006-08-30
06 (System) New version available: draft-shirey-secgloss-v2-06.txt
2006-08-25
05 (System) New version available: draft-shirey-secgloss-v2-05.txt
2006-03-23
04 (System) New version available: draft-shirey-secgloss-v2-04.txt
2006-02-21
03 (System) New version available: draft-shirey-secgloss-v2-03.txt
2005-11-11
02 (System) New version available: draft-shirey-secgloss-v2-02.txt
2005-03-09
01 (System) New version available: draft-shirey-secgloss-v2-01.txt
2004-08-23
00 (System) New version available: draft-shirey-secgloss-v2-00.txt