doc/standardisation/draft-howard-gss-sanon-13.txt

   1
   2
   3
   4
   5 Network Working Group                                          L. Howard
   6 Internet-Draft                                                      PADL
   7 Intended status: Informational                            April 27, 2020
   8 Expires: October 29, 2020
   9
  10
  11                   A Simple Anonymous GSS-API Mechanism
  12                        draft-howard-gss-sanon-13
  13
  14 Abstract
  15
  16    This document defines protocols, procedures and conventions for a
  17    Generic Security Service Application Program Interface (GSS-API)
  18    security mechanism that provides key agreement without authentication
  19    of either party.
  20
  21 Status of This Memo
  22
  23    This Internet-Draft is submitted in full conformance with the
  24    provisions of BCP 78 and BCP 79.
  25
  26    Internet-Drafts are working documents of the Internet Engineering
  27    Task Force (IETF).  Note that other groups may also distribute
  28    working documents as Internet-Drafts.  The list of current Internet-
  29    Drafts is at https://datatracker.ietf.org/drafts/current/.
  30
  31    Internet-Drafts are draft documents valid for a maximum of six months
  32    and may be updated, replaced, or obsoleted by other documents at any
  33    time.  It is inappropriate to use Internet-Drafts as reference
  34    material or to cite them other than as "work in progress."
  35
  36    This Internet-Draft will expire on October 29, 2020.
  37
  38 Copyright Notice
  39
  40    Copyright (c) 2020 IETF Trust and the persons identified as the
  41    document authors.  All rights reserved.
  42
  43    This document is subject to BCP 78 and the IETF Trust's Legal
  44    Provisions Relating to IETF Documents
  45    (https://trustee.ietf.org/license-info) in effect on the date of
  46    publication of this document.  Please review these documents
  47    carefully, as they describe your rights and restrictions with respect
  48    to this document.  Code Components extracted from this document must
  49    include Simplified BSD License text as described in Section 4.e of
  50    the Trust Legal Provisions and are provided without warranty as
  51    described in the Simplified BSD License.
  52
  53
  54
  55
  56 Howard                  Expires October 29, 2020                [Page 1]
  57 \f
  58 Internet-Draft           SAnon GSS-API Mechanism              April 2020
  59
  60
  61 Table of Contents
  62
  63    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
  64    2.  Requirements notation . . . . . . . . . . . . . . . . . . . .   2
  65    3.  Discovery and Negotiation . . . . . . . . . . . . . . . . . .   3
  66    4.  Naming  . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
  67    4.1.  Mechanism Names . . . . . . . . . . . . . . . . . . . . . .   3
  68    4.2.  Display Name Format . . . . . . . . . . . . . . . . . . . .   3
  69    4.3.  Exported Name Format  . . . . . . . . . . . . . . . . . . .   3
  70    5.  Definitions and Token Formats . . . . . . . . . . . . . . . .   4
  71    5.1.  Context Establishment Tokens  . . . . . . . . . . . . . . .   4
  72    5.1.1.  Initial context token . . . . . . . . . . . . . . . . . .   4
  73    5.1.2.  Acceptor context token  . . . . . . . . . . . . . . . . .   5
  74    5.1.3.  Initiator context completion  . . . . . . . . . . . . . .   5
  75    5.2.  Per-Message Tokens  . . . . . . . . . . . . . . . . . . . .   6
  76    5.3.  Context Deletion Tokens . . . . . . . . . . . . . . . . . .   6
  77    6.  Key derivation  . . . . . . . . . . . . . . . . . . . . . . .   6
  78    7.  Pseudo-Random Function  . . . . . . . . . . . . . . . . . . .   7
  79    8.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
  80    9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
  81    10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
  82    10.1.  Normative References . . . . . . . . . . . . . . . . . . .   7
  83    10.2.  Informative References . . . . . . . . . . . . . . . . . .   8
  84    Appendix A.  Test Vectors . . . . . . . . . . . . . . . . . . . .   9
  85    Appendix B.  Mechanism Attributes . . . . . . . . . . . . . . . .  10
  86    Appendix C.  NegoEx . . . . . . . . . . . . . . . . . . . . . . .  10
  87    Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  11
  88
  89 1.  Introduction
  90
  91    The Generic Security Service Application Program Interface (GSS-API)
  92    [RFC2743] provides a framework for authentication and message
  93    protection services through a common programming interface.
  94
  95    The Simple Anonymous mechanism (hereafter SAnon) described in this
  96    document is a simple protocol based on the X25519 elliptic curve
  97    Diffie-Hellman (ECDH) key agreement scheme defined in [RFC7748].  No
  98    authentication of initiator or acceptor is provided.  A potential use
  99    of SAnon is to provide a degree of privacy when bootstrapping unkeyed
 100    entities.
 101
 102 2.  Requirements notation
 103
 104    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 105    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 106    document are to be interpreted as described in [RFC2119].
 107
 108
 109
 110
 111
 112 Howard                  Expires October 29, 2020                [Page 2]
 113 \f
 114 Internet-Draft           SAnon GSS-API Mechanism              April 2020
 115
 116
 117 3.  Discovery and Negotiation
 118
 119    The SAnon mechanism is identified by the following OID:
 120
 121        sanon-x25519 OBJECT IDENTIFIER ::=
 122            {iso(1)identified-organization(3)dod(6)internet(1)
 123             private(4)enterprise(1)padl(5322)gss-sanon(26)
 124             mechanisms(1)sanon-x25519(110)}
 125
 126    The means of discovering GSS-API peers and their supported mechanisms
 127    is out of this specification's scope.  To avoid multiple layers of
 128    negotiation, SAnon is not crypto-agile; a future variant using a
 129    different algorithm would be assigned a different OID.
 130
 131    If anonymity is not desired then SAnon MUST NOT be used.  Either
 132    party can test for anon_state (GSS_C_ANON_FLAG) to check if anonymous
 133    authentication was performed.
 134
 135 4.  Naming
 136
 137 4.1.  Mechanism Names
 138
 139    A SAnon mechanism name is abstractly a boolean indicating whether it
 140    represents an anonymous identity.  Anonymous identities are names
 141    imported with the GSS_C_NT_ANONYMOUS name type.  Implementations MAY
 142    map other names to anonymous identities according to local policy.
 143    Names representing non-anonymous identities MUST be importable so
 144    that initiators with non-default credentials can engage SAnon by
 145    setting anon_req_flag (GSS_C_ANON_FLAG).
 146
 147 4.2.  Display Name Format
 148
 149    When GSS_Display_name() is called on a mechanism name representing an
 150    anonymous identity, the display string is WELLKNOWN/
 151    ANONYMOUS@WELLKNOWN:ANONYMOUS [RFC8062] and the name type is
 152    GSS_C_NT_ANONYMOUS.  This is always the name observed by a SAnon
 153    peer.  All context APIs that return peer names MUST return this name
 154    for both parties if the context is established.
 155
 156 4.3.  Exported Name Format
 157
 158    SAnon uses the mechanism-independent exported name object format
 159    defined in [RFC2743] Section 3.2.  All lengths are encoded as big-
 160    endian integers.  The export of non-anonymous mechanism names MUST
 161    fail with GSS_S_BAD_NAME.
 162
 163
 164
 165
 166
 167
 168 Howard                  Expires October 29, 2020                [Page 3]
 169 \f
 170 Internet-Draft           SAnon GSS-API Mechanism              April 2020
 171
 172
 173      +--------------+--------------+---------------------------------+
 174      | Length       | Name         | Description                     |
 175      +--------------+--------------+---------------------------------+
 176      | 2            | TOK_ID       | 04 01                           |
 177      |              |              |                                 |
 178      | 2            | MECH_OID_LEN | Length of the mechanism OID     |
 179      |              |              |                                 |
 180      | MECH_OID_LEN | MECH_OID     | The SAnon mechanism OID, in DER |
 181      |              |              |                                 |
 182      | 4            | NAME_LEN     | 00 00 00 01                     |
 183      |              |              |                                 |
 184      | 1            | NAME         | 01                              |
 185      +--------------+--------------+---------------------------------+
 186
 187 5.  Definitions and Token Formats
 188
 189 5.1.  Context Establishment Tokens
 190
 191 5.1.1.  Initial context token
 192
 193    The initial context token is framed per Section 1 of [RFC2743]:
 194
 195    GSS-API DEFINITIONS ::=
 196        BEGIN
 197
 198        MechType ::= OBJECT IDENTIFIER -- 1.3.6.1.4.1.5322.26.1.110
 199        GSSAPI-Token ::=
 200        [APPLICATION 0] IMPLICIT SEQUENCE {
 201             thisMech MechType,
 202             innerToken ANY DEFINED BY thisMech
 203                 -- 32 byte initiator public key
 204                 -- 8 byte protocol flags (optional)
 205        }
 206        END
 207
 208    On the first call to GSS_Init_sec_context(), the mechanism checks if
 209    one or more of the following are true:
 210
 211       The caller set anon_req_flag (GSS_C_ANON_FLAG)
 212
 213       The claimant credential identity is anonymous (see Section 4.1)
 214
 215       The claimant credential is the default one and target identity is
 216       anonymous
 217
 218    If none of these are the case, the call MUST fail with
 219    GSS_S_UNAVAILABLE.
 220
 221
 222
 223
 224 Howard                  Expires October 29, 2020                [Page 4]
 225 \f
 226 Internet-Draft           SAnon GSS-API Mechanism              April 2020
 227
 228
 229    If proceeding, the initiator generates a fresh secret and public key
 230    pair per [RFC7748] Section 6.1 and returns GSS_S_CONTINUE_NEEDED,
 231    indicating that a subsequent context token from the acceptor is
 232    expected.  The innerToken field of the output_token contains the
 233    initiator's 32 byte public key, optionally concatenated with a 64-bit
 234    big-endian integer containing flags the acceptor would be otherwise
 235    be unable to infer (such as those defined in [RFC4757] Section 7.1).
 236
 237    Portable initiators are RECOMMENDED to use default credentials
 238    whenever possible and request anonymity only through anon_req_flag
 239    (see [RFC8062] Section 6).
 240
 241 5.1.2.  Acceptor context token
 242
 243    Upon receiving a context token from the initiator, the acceptor
 244    validates that the token is well formed and contains a public key of
 245    the requisite length.  The acceptor generates a fresh secret and
 246    public key pair.  The context session key is computed as specified in
 247    Section 6.
 248
 249    The acceptor constructs an output_token by concatenating its public
 250    key with the token emitted by calling GSS_GetMIC() with the default
 251    QOP and zero-length octet string.  The output token is sent to the
 252    initiator without additional framing.
 253
 254    The acceptor then returns GSS_S_COMPLETE, setting src_name to the
 255    canonical anonymous name.  The reply_det_state (GSS_C_REPLAY_FLAG),
 256    sequence_state (GSS_C_SEQUENCE_FLAG), conf_avail (GSS_C_CONF_FLAG),
 257    integ_avail (GSS_C_INTEG_FLAG) and anon_state (GSS_C_ANON_FLAG)
 258    security context flags are set, along with any additional flags
 259    received from the initiator.  The context is ready to use.
 260
 261 5.1.3.  Initiator context completion
 262
 263    Upon receiving the acceptor context token and verifying it is well
 264    formed, the initiator extracts the acceptor's public key (being the
 265    first 32 bytes of the input token) and computes the context session
 266    key per Section 6.
 267
 268    The initiator calls GSS_VerifyMIC() with the MIC extracted from the
 269    context token and the zero-length octet string.  If successful, the
 270    initiator returns GSS_S_COMPLETE to the caller, to indicate the
 271    initiator is authenticated and the context is ready for use.  No
 272    output token is emitted.  Supported security context flags are as for
 273    the acceptor context.  The flags returned to the caller are the
 274    intersection of supported and requested flags, combined with
 275    anon_state (GSS_C_ANON_FLAG) which is set unconditionally.
 276
 277
 278
 279
 280 Howard                  Expires October 29, 2020                [Page 5]
 281 \f
 282 Internet-Draft           SAnon GSS-API Mechanism              April 2020
 283
 284
 285 5.2.  Per-Message Tokens
 286
 287    The per-message tokens definitions are imported from [RFC4121]
 288    Section 4.2.  The base key used to derive specific keys for signing
 289    and sealing messages is defined in Section 6.  The [RFC3961]
 290    encryption and checksum algorithms use the aes128-cts-hmac-sha256-128
 291    encryption type defined in [RFC8009].  The AcceptorSubkey flag as
 292    defined in [RFC4121] Section 4.2.2 MUST be set.
 293
 294 5.3.  Context Deletion Tokens
 295
 296    Context deletion tokens are empty in this mechanism.  The behavior of
 297    GSS_Delete_sec_context() [RFC2743] is as specified in [RFC4121]
 298    Section 4.3.
 299
 300 6.  Key derivation
 301
 302    The context session key is known as the base key, and is computed
 303    using a key derivation function from [SP800-108] Section 5.1 (using
 304    HMAC as the PRF):
 305
 306        base key = HMAC-SHA-256(K1, i | label | 0x00 | context | L)
 307
 308    where:
 309
 310    K1            the output of X25519(local secret key, peer public key)
 311                  as specified in [RFC7748] Section 6.1
 312
 313    i             the constant 0x00000001, representing the iteration
 314                  count expressed in big-endian binary representation of
 315                  4 bytes
 316
 317    label         the string "sanon-x25519" (without quotation marks)
 318
 319    context       initiator public key | acceptor public key | flags |
 320                  channel binding application data (if present)
 321
 322    L             the constant 0x00000080, being length in bits of the
 323                  key to be outputted expressed in big-endian binary
 324                  representation of 4 bytes
 325
 326    The flags input to the context contains any flags sent by the
 327    initiator, defaulting to zero if none were sent, expressed in big-
 328    endian binary representation of 8 bytes.
 329
 330    The inclusion of channel bindings in the key derivation function
 331    means that the acceptor cannot ignore initiator channel bindings;
 332    this differs from some other mechanisms.
 333
 334
 335
 336 Howard                  Expires October 29, 2020                [Page 6]
 337 \f
 338 Internet-Draft           SAnon GSS-API Mechanism              April 2020
 339
 340
 341    The base key provides the acceptor-asserted subkey defined in
 342    [RFC4121] Section 2 and is used to generate keys for per-message
 343    tokens and the GSS-API PRF.  Its encryption type is aes128-cts-hmac-
 344    sha256-128 per [RFC8009].  The [RFC3961] algorithm protocol
 345    parameters are as given in [RFC8009] Section 5.
 346
 347 7.  Pseudo-Random Function
 348
 349    The [RFC4401] GSS-API pseudo-random function for this mechanism
 350    imports the definitions from [RFC8009], using the base key for both
 351    GSS_C_PRF_KEY_FULL and GSS_C_PRF_KEY_PARTIAL usages.
 352
 353 8.  Security Considerations
 354
 355    This document defines a GSS-API security mechanism, and therefore
 356    deals in security and has security considerations text embedded
 357    throughout.  This section only addresses security considerations
 358    associated with the SAnon mechanism described in this document.  It
 359    does not address security considerations associated with the GSS-API
 360    itself.
 361
 362    This mechanism provides only for key agreement.  It does not
 363    authenticate the identity of either party.  It MUST NOT be selected
 364    if either party requires identification of its peer.
 365
 366    SAnon mechanism names are not unary.  Implementations MUST ensure
 367    that GSS_Compare_name() always sets name_equal to FALSE when
 368    comparing mechanism names.
 369
 370 9.  Acknowledgements
 371
 372    AuriStor, Inc funded the design of this protocol, along with an
 373    implementation for the Heimdal GSS-API library.
 374
 375    Jeffrey Altman, Greg Hudson, Simon Josefsson, and Nicolas Williams
 376    provided valuable feedback on this document.
 377
 378 10.  References
 379
 380 10.1.  Normative References
 381
 382    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
 383               Requirement Levels", BCP 14, RFC 2119,
 384               DOI 10.17487/RFC2119, March 1997,
 385               <https://www.rfc-editor.org/info/rfc2119>.
 386
 387
 388
 389
 390
 391
 392 Howard                  Expires October 29, 2020                [Page 7]
 393 \f
 394 Internet-Draft           SAnon GSS-API Mechanism              April 2020
 395
 396
 397    [RFC2743]  Linn, J., "Generic Security Service Application Program
 398               Interface Version 2, Update 1", RFC 2743,
 399               DOI 10.17487/RFC2743, January 2000,
 400               <https://www.rfc-editor.org/info/rfc2743>.
 401
 402    [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
 403               Kerberos 5", RFC 3961, DOI 10.17487/RFC3961, February
 404               2005, <https://www.rfc-editor.org/info/rfc3961>.
 405
 406    [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
 407               Version 5 Generic Security Service Application Program
 408               Interface (GSS-API) Mechanism: Version 2", RFC 4121,
 409               DOI 10.17487/RFC4121, July 2005,
 410               <https://www.rfc-editor.org/info/rfc4121>.
 411
 412    [RFC4401]  Williams, N., "A Pseudo-Random Function (PRF) API
 413               Extension for the Generic Security Service Application
 414               Program Interface (GSS-API)", RFC 4401,
 415               DOI 10.17487/RFC4401, February 2006,
 416               <https://www.rfc-editor.org/info/rfc4401>.
 417
 418    [RFC7748]  Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
 419               for Security", RFC 7748, DOI 10.17487/RFC7748, January
 420               2016, <https://www.rfc-editor.org/info/rfc7748>.
 421
 422    [RFC8009]  Jenkins, M., Peck, M., and K. Burgin, "AES Encryption with
 423               HMAC-SHA2 for Kerberos 5", RFC 8009, DOI 10.17487/RFC8009,
 424               October 2016, <https://www.rfc-editor.org/info/rfc8009>.
 425
 426 10.2.  Informative References
 427
 428    [I-D.zhu-negoex]
 429               Short, M., Zhu, L., Damour, K., and D. McPherson, "SPNEGO
 430               Extended Negotiation (NEGOEX) Security Mechanism", draft-
 431               zhu-negoex-04 (work in progress), January 2011.
 432
 433    [RFC4178]  Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
 434               Simple and Protected Generic Security Service Application
 435               Program Interface (GSS-API) Negotiation Mechanism",
 436               RFC 4178, DOI 10.17487/RFC4178, October 2005,
 437               <https://www.rfc-editor.org/info/rfc4178>.
 438
 439    [RFC4757]  Jaganathan, K., Zhu, L., and J. Brezak, "The RC4-HMAC
 440               Kerberos Encryption Types Used by Microsoft Windows",
 441               RFC 4757, DOI 10.17487/RFC4757, December 2006,
 442               <https://www.rfc-editor.org/info/rfc4757>.
 443
 444
 445
 446
 447
 448 Howard                  Expires October 29, 2020                [Page 8]
 449 \f
 450 Internet-Draft           SAnon GSS-API Mechanism              April 2020
 451
 452
 453    [RFC5587]  Williams, N., "Extended Generic Security Service Mechanism
 454               Inquiry APIs", RFC 5587, DOI 10.17487/RFC5587, July 2009,
 455               <https://www.rfc-editor.org/info/rfc5587>.
 456
 457    [RFC8062]  Zhu, L., Leach, P., Hartman, S., and S. Emery, Ed.,
 458               "Anonymity Support for Kerberos", RFC 8062,
 459               DOI 10.17487/RFC8062, February 2017,
 460               <https://www.rfc-editor.org/info/rfc8062>.
 461
 462    [SP800-108]
 463               Chen, L., "Recommendation for Key Derivation Using
 464               Pseudorandom Functions (Revised)", October 2009.
 465
 466 Appendix A.  Test Vectors
 467
 468    The example exchange below contains no extra flags or channel binding
 469    information.
 470
 471    initiator secret key  83 33 f2 ea 2a 22 eb aa 05 39 c6 06 1d 6a 99 05
 472                          84 24 49 9e 2c 16 c1 b1 34 d9 22 27 f3 f4 5e bd
 473
 474    initiator public key  5f 40 66 22 5a 3c fd 72 57 23 c1 8f ae 71 3e 8c
 475                          ab 32 a7 2c 93 b9 76 66 04 4b 8f e4 a0 c9 69 19
 476
 477    initiator token       60 2c 06 0a 2b 06 01 04 01 a9 4a 1a 01 6e 5f 40
 478                          66 22 5a 3c fd 72 57 23 c1 8f ae 71 3e 8c ab 32
 479                          a7 2c 93 b9 76 66 04 4b 8f e4 a0 c9 69 1
 480
 481    acceptor secret key   b0 db 16 32 39 0a dd 93 1e f7 62 bc d3 c9 1d 03
 482                          e8 d9 59 52 48 eb e2 f2 b5 f7 d8 06 ec dd 50 60
 483
 484    acceptor public key   2f 81 51 9f a8 9c 07 f8 eb b2 95 6c 0c c3 22 77
 485                          ae a1 0e 62 0c 79 33 81 ef 9a c5 b2 f0 d9 1e 06
 486
 487    base key              80 76 2c 43 32 6a 95 f5 be 30 6d ea 10 ba f3 d0
 488
 489    acceptor token        2f 81 51 9f a8 9c 07 f8 eb b2 95 6c 0c c3 22 77
 490                          ae a1 0e 62 0c 79 33 81 ef 9a c5 b2 f0 d9 1e 06
 491                          04 04 05 ff ff ff ff ff 00 00 00 00 00 00 00 00
 492                          4d 5e a9 e0 e1 9c 7a 61 c2 6a 9a c5 e8 17 5f 04
 493
 494    initiator negoex key  2a c8 f9 d0 31 87 40 42 cb d4 50 07 ce db c2 c2
 495
 496    acceptor negoex key   73 9f 4d a2 f1 2d f7 f7 d7 ea e4 9d a4 08 62 5b
 497
 498
 499
 500
 501
 502
 503
 504 Howard                  Expires October 29, 2020                [Page 9]
 505 \f
 506 Internet-Draft           SAnon GSS-API Mechanism              April 2020
 507
 508
 509 Appendix B.  Mechanism Attributes
 510
 511    The [RFC5587] mechanism attributes for this mechanism are:
 512
 513       GSS_C_MA_MECH_CONCRETE
 514
 515       GSS_C_MA_ITOK_FRAMED
 516
 517       GSS_C_MA_AUTH_INIT_ANON
 518
 519       GSS_C_MA_AUTH_TARG_ANON
 520
 521       GSS_C_MA_INTEG_PROT
 522
 523       GSS_C_MA_CONF_PROT
 524
 525       GSS_C_MA_MIC
 526
 527       GSS_C_MA_WRAP
 528
 529       GSS_C_MA_REPLAY_DET
 530
 531       GSS_C_MA_OOS_DET
 532
 533       GSS_C_MA_CBINDINGS
 534
 535       GSS_C_MA_PFS
 536
 537       GSS_C_MA_CTX_TRANS
 538
 539 Appendix C.  NegoEx
 540
 541    When SAnon is negotiated by [I-D.zhu-negoex], the authentication
 542    scheme identifier is DEE384FF-1086-4E86-BE78-B94170BFD376.
 543
 544    The initiator and acceptor keys for NegoEx checksum generation and
 545    verification are derived using the GSS-API PRF (see Section 7), with
 546    the input data "sanon-x25519-initiator-negoex-key" and "sanon-x25519-
 547    acceptor-negoex-key" respectively (without quotation marks).  No
 548    metadata is defined and any, if present, SHOULD be ignored.
 549
 550    It is RECOMMENDED that GSS-API implementations supporting both SPNEGO
 551    [RFC4178] and NegoEx advertise SAnon under both to maximise
 552    interoperability.
 553
 554
 555
 556
 557
 558
 559
 560 Howard                  Expires October 29, 2020               [Page 10]
 561 \f
 562 Internet-Draft           SAnon GSS-API Mechanism              April 2020
 563
 564
 565 Author's Address
 566
 567    Luke Howard
 568    PADL Software Pty Ltd
 569    PO Box 59
 570    Central Park, VIC  3145
 571    Australia
 572
 573    Email: lukeh@padl.com
 574
 575
 576
 577
 578
 579
 580
 581
 582
 583
 584
 585
 586
 587
 588
 589
 590
 591
 592
 593
 594
 595
 596
 597
 598
 599
 600
 601
 602
 603
 604
 605
 606
 607
 608
 609
 610
 611
 612
 613
 614
 615
 616 Howard                  Expires October 29, 2020               [Page 11]