RFC 5904

RADIUS Attributes for IEEE 802.16 Privacy Key Management Version 1 (PKMv1) Protocol Support

📅 published June 2010, from ietf

RFC 5904 🎀 Part 1 of 3

RADIUS Attributes for IEEE 802.16 Privacy Key Management Version 1 (PKMv1) Protocol Support 💖

Okay bestie, here's the title block. It's an Informational RFC from the IETF, written by G. Zorn of Network Zen, dated June 2010. It's published as ISSN 2070-1721. The header doesn't list anything it obsoletes or updates, so it stands on its own 🦋.

Abstract 🌸

This doc defines a set of Remote Authentication Dial-In User Service (RADIUS) Attributes built to give RADIUS support for IEEE 802.16 Privacy Key Management Version 1. ✨

Status of This Memo 📜

This one is not an Internet Standards Track spec. It's published just for information purposes 💅.

This doc is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, received public review, and got approved for publication by the Internet Engineering Steering Group (IESG). Not every doc the IESG approves is a candidate for any level of Internet Standard, so check out Section 2 of RFC 5741 for the details 🤓.

For the current status, any errata, and how to give feedback, look at http://www.rfc-editor.org/info/rfc5904 🔗.

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document. Code Components pulled from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License.

This document may contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The people controlling the copyright in some of that material may not have granted the IETF Trust the right to allow modifications outside the IETF Standards Process. Without getting an adequate license from those people, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌈.

Table of Contents 🧚

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
2.  Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
3.  Attributes . . . . . . . . . . . . . . . . . . . . . . . . . .  3
  3.1.  PKM-SS-Cert  . . . . . . . . . . . . . . . . . . . . . . .  4
  3.2.  PKM-CA-Cert  . . . . . . . . . . . . . . . . . . . . . . .  5
  3.3.  PKM-Config-Settings  . . . . . . . . . . . . . . . . . . .  6
  3.4.  PKM-Cryptosuite-List . . . . . . . . . . . . . . . . . . .  8
  3.5.  PKM-SAID . . . . . . . . . . . . . . . . . . . . . . . . .  9
  3.6.  PKM-SA-Descriptor  . . . . . . . . . . . . . . . . . . . .  9
  3.7.  PKM-AUTH-Key . . . . . . . . . . . . . . . . . . . . . . . 10
    3.7.1.  AUTH-Key Protection  . . . . . . . . . . . . . . . . . 12
4.  Table of Attributes  . . . . . . . . . . . . . . . . . . . . . 12
5.  Diameter Considerations  . . . . . . . . . . . . . . . . . . . 13
6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
8.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
  10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
  10.2. Informative References . . . . . . . . . . . . . . . . . . 14

1. Introduction 💫

Privacy Key Management Version 1 (PKMv1) [IEEE.802.16-2004] is a public-key-based authentication and key establishment protocol. You'll usually find it in fixed wireless broadband deployments 📡. It uses X.509 v3 certificates [RFC2459], RSA encryption [RFC2437], and a bunch of secret key cryptographic methods so that an 802.16 Base Station (BS) can authenticate a Subscriber Station (SS), then handle key establishment and maintenance between the SS and the BS 🔐.

This doc defines a set of RADIUS Attributes meant to support PKMv1. The audience is developers building RADIUS support for PKMv1, so it assumes you already know RADIUS [RFC2865] and the IEEE 802.16-2004 standard 🧠.

Heads up: this document relies on IEEE.802.16-2004, which references RFC 2437 and RFC 2459, rather than the newer RFCs on RSA and X.509 certificates (for example RFC 3447 and RFC 5280) ⚠️.

2. Acronyms 🔤

  • CA: Certification Authority, a trusted party that issues and signs X.509 certificates.

For more on the following terms, see Section 7 of [IEEE.802.16-2004].

  • SA: Security Association
  • SAID: Security Association Identifier
  • TEK: Traffic Encryption Key

3. Attributes 🎀

The subsections below describe the Attributes this doc defines. This spec covers these values:

   137 PKM-SS-Cert

   138 PKM-CA-Cert

   139 PKM-Config-Settings
   140 PKM-Cryptosuite-List

   141 PKM-SAID

   142 PKM-SA-Descriptor

   143 PKM-Auth-Key

3.1. PKM-SS-Cert 🦋

Description

The PKM-SS-Cert Attribute has variable length and MAY be sent in the Access-Request message. Its Value field is a string holding the X.509 certificate [RFC2459] that binds a public key to the Subscriber Station's identifier 🔑.

The minimum size of an SS certificate is bigger than the maximum size of a RADIUS attribute, so the client MUST wrap the certificate across the Value fields of two or more instances of PKM-SS-Cert. Each one (except possibly the last) is 255 octets long. These multiple PKM-SS-Cert Attributes MUST show up consecutively and in order within the packet. When the RADIUS server gets them, it MUST rebuild the original certificate by joining the Value fields of the received PKM-SS-Cert Attributes in order 🧩.

A quick look at the PKM-SS-Cert Attribute format is below. The fields go from left to right 👀.

                          1                   2
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Type       |      Len      |    Value...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

137 for PKM-SS-Cert

Len

> 2

Value

The Value field has variable length and holds a (possibly complete) piece of an X.509 certificate 💜.

3.2. PKM-CA-Cert 🌷

Description

The PKM-CA-Cert Attribute has variable length and MAY be sent in the Access-Request message. Its Value field is a string holding the X.509 certificate [RFC2459] that the CA used to sign the SS certificate carried in the PKM-SS-Cert attribute (Section 3.1) in the same message 🖊️.

The minimum size of a CA certificate is bigger than the maximum size of a RADIUS attribute, so the client MUST wrap the certificate across the Value fields of two or more instances of PKM-CA-Cert. Each one (except possibly the last) is 255 octets long. These multiple PKM-CA-Cert Attributes MUST show up consecutively and in order within the packet. When the RADIUS server gets them, it MUST rebuild the original certificate by joining the Value fields of the received PKM-CA-Cert Attributes in order 💅.

Here's the PKM-CA-Cert Attribute format, going left to right 👀.

                          1                   2
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Type       |      Len      |    Value...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

138 for PKM-CA-Cert

Len

> 2

Value

The Value field has variable length and holds a (possibly complete) piece of an X.509 certificate 🫶.

3.3. PKM-Config-Settings

Description 🎀

okay so the PKM-Config-Settings Attribute is a string [RFC2865] that's 30 octets long 💅 and it's basically seven independent fields, each one conceptually an unsigned integer ✨. Every field holds a timeout value and matches a Type-Length-Value (TLV) tuple inside the IEEE 802.16 "PKM configuration settings" attribute. If you want the deets on what goes in each field, check Section 11.9.19 of [IEEE.802.16-2004] 🧚. One instance of this attribute MAY be included in the Access-Accept message 💜.

Here's the layout (fields go left to right, always 🫶):

                    1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Type       |      Len      |       Auth Wait Timeout
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    Auth Wait Timeout (cont.)   |      Reauth Wait Timeout
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Reauth Wait Timeout (cont.)  |        Auth Grace Time
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     Auth Grace Time (cont.)    |        Op Wait Timeout
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     Op Wait Timeout (cont.)    |       Rekey Wait Timeout
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Rekey Wait Timeout (cont.)   |         TEK Grace Time
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     TEK Grace Time (cont.)     |     Auth Rej Wait Timeout
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  Auth Rej Wait Timeout (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type 🌸

139 for PKM-Config-Settings

Len 🌸

30

Auth Wait Timeout ✨

The Auth Wait Timeout field is 4 octets long and lines up with the "Authorize wait timeout" field of the 802.16 "PKM configuration settings" attribute.

Reauth Wait Timeout ✨

The Reauth Wait Timeout field is 4 octets long and lines up with the "Reauthorize wait timeout" field of the 802.16 "PKM configuration settings" attribute.

Auth Grace Time ✨

The Auth Grace Time field is 4 octets long and lines up with the "Authorize grace time" field of the 802.16 "PKM configuration settings" attribute.

Op Wait Timeout ✨

The Op Wait Timeout field is 4 octets long and lines up with the "Operational wait timeout" field of the 802.16 "PKM configuration settings" attribute.

Rekey Wait Timeout ✨

The Rekey Wait Timeout field is 4 octets long and lines up with the "Rekey wait timeout" field of the 802.16 "PKM configuration settings" attribute.

TEK Grace Time ✨

The TEK Grace Time field is 4 octets long and lines up with the "TEK grace time" field of the 802.16 "PKM configuration settings" attribute.

Auth Rej Wait Timeout ✨

The Auth Rej Wait Timeout field is 4 octets long and lines up with the "Authorize reject wait timeout" field of the 802.16 "PKM configuration settings" attribute.

3.4. PKM-Cryptosuite-List

Description 🦋

The PKM-Cryptosuite-List Attribute is a string [RFC2865] with variable length 🍓. It's kind of a cousin of the "Cryptographic-Suite-List" 802.16 attribute (see Section 11.19.15 of [IEEE.802.16-2004]). The difference is that the RADIUS Attribute only carries the list of 3-octet cryptographic suite identifiers and skips the IEEE Type and Length fields 💅.

The PKM-Cryptosuite-List Attribute MAY be present in an Access-Request message. Any message that has the PKM-Cryptosuite-List Attribute MUST also contain an instance of the Message-Authenticator Attribute [RFC3579] 🔥.

Implementation Note 💀 The PKM-Cryptosuite-List Attribute is used as a building block to create the 802.16 "Security-Capabilities" attribute ([IEEE.802.16-2004], Section 11.9.13). Since this document only covers PKM version 1, the "Version" sub-attribute in that structure MUST be set to 0x01 when the RADIUS client constructs it.

Here's the layout, left to right as usual:

                    1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Type     |      Len      |          Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type 🌸

140 for PKM-Cryptosuite-List

Len 🌸

2 + 3n < 39, where 'n' is the number of cryptosuite identifiers in the list.

Value ✨

The Value field has variable length and holds a sequence of one or more cryptosuite identifiers. Each identifier is 3 octets long and matches the Value field of an IEEE 802.16 Cryptographic-Suite attribute.

3.5. PKM-SAID

Description 🧚

The PKM-SAID Attribute is a string [RFC2865]. It's 4 octets long and holds a PKM Security Association Identifier ([IEEE.802.16-2004], Section 11.9.7). It MAY be included in an Access-Request message 🌈.

Here's the layout:

                    1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Type     |      Len      |            SAID               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type 🌸

141 for PKM-SAID

Len 🌸

4

SAID ✨

The SAID field is two octets long and corresponds to the Value field of the 802.16 PKM SAID attribute.

3.6. PKM-SA-Descriptor

Description 💜

The PKM-SA-Descriptor Attribute is a string that's 8 octets long. It has three fields, described below, which together describe the characteristics of a PKM security association 👑. One or more instances of the PKM-SA-Descriptor Attribute MAY occur in an Access-Accept message ✨.

Layout time (left to right, obviously):

                    1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Type     |      Len      |            SAID               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    SA Type    |                Cryptosuite                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type 🌸

142 for PKM-SA-Descriptor

Len 🌸

8

SAID ✨

The SAID field is two octets long and contains a PKM SAID (Section 3.5).

SA Type ✨

The SA Type field is one octet long. Its contents correspond to those of the Value field of an IEEE 802.16 SA-Type attribute.

Cryptosuite ✨

The Cryptosuite field is 3 octets long. Its contents correspond to those of the Value field of an IEEE 802.16 Cryptographic-Suite attribute.

3.7. PKM-AUTH-Key

Description 🔥

The PKM-AUTH-Key Attribute is a string that's 135 octets long. It has 3 fields, described below, which together describe the characteristics of a PKM authorization key 🫶. The PKM-AUTH-Key Attribute MAY occur in an Access-Accept message. Any packet that contains an instance of the PKM-AUTH-Key Attribute MUST also contain an instance of the Message-Authenticator Attribute [RFC3579] 🙈.

Here's the layout:

                    1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Type     |      Len      |           Lifetime
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          Lifetime (cont.)      |    Sequence   |     Key...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type 🌸

143 for PKM-AUTH-Key

Len 🌸

135

Lifetime ✨

The Lifetime field is 4 octets long and represents the lifetime, in seconds, of the authorization key. For more info, see Section 11.9.4 of [IEEE.802.16-2004].

Sequence ✨

The Sequence field is one octet long. Its contents correspond to those of the Value field of an IEEE 802.16 Key-Sequence-Number attribute (see [IEEE.802.16-2004], Section 11.9.5).

Key ✨

The Key field is 128 octets long. Its contents correspond to those of the Value field of an IEEE 802.16 AUTH-Key attribute. The Key field MUST be encrypted under the public key from the Subscriber Station certificate (Section 3.1) using RSA encryption [RFC2437]. See Section 7.5 of [IEEE.802.16-2004] for further details 🔐.

Implementation Note 💀 It is necessary that a plaintext copy of this field be returned in the Access-Accept message. Appropriate precautions MUST be taken to ensure the confidentiality of the key.

3.7.1. AUTH-Key Protection

The PKM-AUTH-Key Attribute (Section 3.7) contains the AUTH-Key encrypted with the SS's public key 🔒. The BS also needs the AK, so a second copy of the AK needs to be returned in the Access-Accept message.

It is RECOMMENDED that the AK is encapsulated in an instance of the MS-MPPE-Send-Key Attribute [RFC2548]. However, see Section 4.3.4 of RFC 3579 [RFC3579] for details on the weaknesses in the encryption scheme used 🙈.

If better means for protecting the Auth-Key are available (such as RADIUS key attributes with better security properties, or means of protecting the whole Access-Accept message), they SHOULD be used instead of (or in addition to) the MS-MPPE-Send-Key Attribute 🫶.

4. Table of Attributes 💅

okay so this table is basically the cheat sheet for which attributes can show up in which packets, and how many of each you're allowed to bring 🎀 read the columns like a little map and you're golden

   Request Accept Reject Challenge Acct-Req  #   Attribute
   0+      0      0      0         0        137 PKM-SS-Cert [Note 1]
   0+      0      0      0         0        138 PKM-CA-Cert [Note 2]
   0       0-1    0      0         0        139 PKM-Config-Settings
   0-1     0      0      0         0        140 PKM-Cryptosuite-List
   0-1     0      0      0         0        141 PKM-SAID
   0       0+     0      0         0        142 PKM-SA-Descriptor
   0       0-1    0      0         0        143 PKM-Auth-Key
   0       0-1    0      0         0             MS-MPPE-Send-Key
                                                    [Note 3]

Now the notes, which are super important 👀

[Note 1]

No more than one Subscriber Station Certificate may be transferred in an Access-Request packet. 🔥

[Note 2]

No more than one CA Certificate may be transferred in an Access-Request packet. 🌸

[Note 3] MS-MPPE-Send-Key is one possible attribute that can be used to convey the AK to the BS 🦋 other attributes can be used instead, so check out Section 3.7.1 for the full story 🧚

And here's how to read the entries in the table itself, bestie 💜

0   This attribute MUST NOT be present in packet
0+  Zero or more instances of this attribute MAY be present in packet
0-1 Zero or one instance of this attribute MAY be present in packet
1   Exactly one instance of this attribute MUST be present in packet

5. Diameter Considerations 🌈

Quick and easy one 🫶 because these Attributes come from the standard RADIUS type space (see Section 7), Diameter nodes don't need any special handling. No extra work, no drama ✨

6. Security Considerations 💀

okay this section is serious, so I'm going to keep it real with you 😭 the security stuff matters, no cap 🔒

Section 4 of RFC 3579 [RFC3579] talks about the vulnerabilities of the RADIUS protocol itself, so go read that if you want the deep dive 📚

Section 3 of the paper "Security Enhancements for Privacy and Key Management Protocol in IEEE 802.16e-2005" [SecEn] goes into how PKMv1 works and where it's vulnerable 🙈

If the Access-Request message is not subject to strong integrity protection, an attacker may be able to modify the contents of the PKM-Cryptosuite-List Attribute, weakening 802.16 security or disabling data encryption altogether. This is a full-on villain moment, so please protect your Access-Request messages 🚨
If the Access-Accept message is not subject to strong integrity protection, an attacker may be able to modify the contents of the PKM-Auth-Key Attribute. For example, the Key field could be replaced with a key known to the attacker. Lowkey terrifying, highkey something you have to lock down 😱

See Section 3.7.1 for the security considerations of sending the authorization key to the BS 🔐

7. IANA Considerations 🎀

IANA has assigned numbers for the following Attributes, so these are officially claimed 👑

  • 137 PKM-SS-Cert
  • 138 PKM-CA-Cert
  • 139 PKM-Config-Settings
  • 140 PKM-Cryptosuite-List
  • 141 PKM-SAID
  • 142 PKM-SA-Descriptor
  • 143 PKM-Auth-Key

New Attribute numbers get allocated from the standard RADIUS Attribute type space, following the "IETF Review" policy [RFC5226] 📋 no going rogue with the numbers, periodt 💅

8. Contributors 🫶

Pasi Eronen wrote most of the text in Section 3.7.1, so huge shoutout to him ✨

9. Acknowledgements 🌸

Thank you (in no particular order) to Bernard Aboba, Donald Eastlake, Dan Romascanu, Avshalom Houri, Juergen Quittek, Pasi Eronen, and Alan DeKok for their mostly useful reviews of this document 💖 "mostly useful" is giving honest feedback energy and I respect it 😭

10. References 📚

10.1. Normative References 🔥

[IEEE.802.16-2004]
           Institute of Electrical and Electronics Engineers, "IEEE
           Standard for Local and metropolitan area networks, Part
           16: Air Interface for Fixed Broadband Wireless Access
           Systems", IEEE Standard 802.16, October 2004.

[RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
           "Remote Authentication Dial In User Service (RADIUS)",
           RFC 2865, June 2000.

[RFC3579]  Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
           Dial In User Service) Support For Extensible
           Authentication Protocol (EAP)", RFC 3579, September 2003.

[RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
           IANA Considerations Section in RFCs", BCP 26, RFC 5226,
           May 2008.

10.2. Informative References 🦋

[RFC2437]  Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography
           Specifications Version 2.0", RFC 2437, October 1998.

[RFC2459]  Housley, R., Ford, W., Polk, T., and D. Solo, "Internet
           X.509 Public Key Infrastructure Certificate and CRL
           Profile", RFC 2459, January 1999.

[RFC2548]  Zorn, G., "Microsoft Vendor-specific RADIUS Attributes",
           RFC 2548, March 1999.

[SecEn]    Altaf, A., Jawad, M., and A. Ahmed, "Security Enhancements
           for Privacy and Key Management Protocol in IEEE 802.16e-
           2005", Ninth ACIS International Conference on Software
           Engineering, Artificial Intelligence, Networking, and
           Parallel/Distributed Computing, 2008.

Author's Address 🖊️

Glen Zorn
Network Zen
1463 East Republican Street
#358
Seattle, WA  98112
US

EMail: gwz@net-zen.net
📦 where this page comes from