source4/heimdal/doc/standardisation/draft-perez-krb-wg-gss-preauth-02.txt

   1
   2
   3
   4 Kerberos Working Group                                   A. Perez-Mendez
   5 Internet-Draft                                            R. Marin-Lopez
   6 Intended status: Experimental                       F. Pereniguez-Garcia
   7 Expires: March 5, 2013                                   G. Lopez-Millan
   8                                                     University of Murcia
   9                                                                 Sep 2012
  10
  11
  12                 GSS-API pre-authentication for Kerberos
  13                    draft-perez-krb-wg-gss-preauth-02
  14
  15 Abstract
  16
  17    This document describes a pre-authentication mechanism for Kerberos
  18    based on the Generic Security Service Application Program Interface
  19    (GSS-API), which allows a Key Distribution Center (KDC) to
  20    authenticate clients by using a GSS mechanism.
  21
  22 Status of this Memo
  23
  24    This Internet-Draft is submitted in full conformance with the
  25    provisions of BCP 78 and BCP 79.
  26
  27    Internet-Drafts are working documents of the Internet Engineering
  28    Task Force (IETF).  Note that other groups may also distribute
  29    working documents as Internet-Drafts.  The list of current Internet-
  30    Drafts is at http://datatracker.ietf.org/drafts/current/.
  31
  32    Internet-Drafts are draft documents valid for a maximum of six months
  33    and may be updated, replaced, or obsoleted by other documents at any
  34    time.  It is inappropriate to use Internet-Drafts as reference
  35    material or to cite them other than as "work in progress."
  36
  37    This Internet-Draft will expire on March 5, 2013.
  38
  39 Copyright Notice
  40
  41    Copyright (c) 2012 IETF Trust and the persons identified as the
  42    document authors.  All rights reserved.
  43
  44    This document is subject to BCP 78 and the IETF Trust's Legal
  45    Provisions Relating to IETF Documents
  46    (http://trustee.ietf.org/license-info) in effect on the date of
  47    publication of this document.  Please review these documents
  48    carefully, as they describe your rights and restrictions with respect
  49    to this document.  Code Components extracted from this document must
  50    include Simplified BSD License text as described in Section 4.e of
  51    the Trust Legal Provisions and are provided without warranty as
  52
  53
  54
  55 Perez-Mendez, et al.      Expires March 5, 2013                 [Page 1]
  56 \f
  57 Internet-Draft                 GSS preauth                      Sep 2012
  58
  59
  60    described in the Simplified BSD License.
  61
  62
  63 Table of Contents
  64
  65    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
  66      1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  4
  67    2.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .  4
  68    3.  Definition of the Kerberos GSS padata  . . . . . . . . . . . .  4
  69    4.  GSS Pre-authentication Operation . . . . . . . . . . . . . . .  5
  70      4.1.  Generation of GSS preauth requests . . . . . . . . . . . .  5
  71      4.2.  Processing of GSS preauth requests . . . . . . . . . . . .  6
  72      4.3.  Generation of GSS preauth responses  . . . . . . . . . . .  6
  73      4.4.  Processing of GSS preauth responses  . . . . . . . . . . .  7
  74    5.  Data in the KDC_ERR_PREAUTH_REQUIRED . . . . . . . . . . . . .  7
  75    6.  Derivation of the reply key from the GSS context . . . . . . .  7
  76    7.  KDC state management . . . . . . . . . . . . . . . . . . . . .  8
  77    8.  Support for federated users  . . . . . . . . . . . . . . . . .  8
  78    9.  GSS channel bindings . . . . . . . . . . . . . . . . . . . . .  9
  79    10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
  80    11. Security Considerations  . . . . . . . . . . . . . . . . . . .  9
  81    12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
  82    13. Normative References . . . . . . . . . . . . . . . . . . . . .  9
  83    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
  84
  85
  86
  87
  88
  89
  90
  91
  92
  93
  94
  95
  96
  97
  98
  99
 100
 101
 102
 103
 104
 105
 106
 107
 108
 109
 110
 111 Perez-Mendez, et al.      Expires March 5, 2013                 [Page 2]
 112 \f
 113 Internet-Draft                 GSS preauth                      Sep 2012
 114
 115
 116 1.  Introduction
 117
 118    The GSS-API (Generic Security Service Application Programming
 119    Interface) [RFC2743] provides a generic toolset of functions that
 120    allow applications to establish security contexts in order to protect
 121    their communications through security services such as
 122    authentication, confidentiality and integrity protection.  Thanks to
 123    the GSS-API, applications remain independent from the specific
 124    underlying mechanism used to establish the context and provide
 125    security.
 126
 127    On the other hand, Kerberos [RFC4120] defines a process called pre-
 128    authentication.  This feature is intended to avoid the security risk
 129    of providing tickets encrypted with the user's long-term key to
 130    attackers, by requiring clients to proof their knowledge over these
 131    credentials.  The execution of a pre-authentication mechanism may
 132    require the exchange of several KRB_AS_REQ/KRB_ERROR messages before
 133    the KDC delivers the TGT requested by the client within a KRB_AS_REP.
 134    These messages transport authentication information by means of pre-
 135    authentication elements.
 136
 137    There exists a variety of pre-authentication mechanisms, like PKINIT
 138    [RFC4556] and encrypted time-stamp [RFC4120].  Furthermore,
 139    [I-D.ietf-krb-wg-preauth-framework] provides a generic framework for
 140    Kerberos pre-authentication, which aims to describe the features that
 141    a pre-authentication mechanism may provide (e.g. mutual
 142    authentication, replace reply key, etc.).  Additionally, in order to
 143    simplify the definition of new pre-authentication mechanisms, it
 144    defines a mechanism called FAST (Flexible Authentication Secure
 145    Tunneling), which provides a generic and secure transport for pre-
 146    authentication elements.  More specifically, FAST establishes a
 147    secure tunnel providing confidentiality and integrity protection
 148    between the client and the KDC prior to the exchange of any specific
 149    pre-authentication data.  Within this tunnel, different pre-
 150    authentication methods can be executed.  This inner mechanism is
 151    called a FAST factor.  It is important to note that FAST factors
 152    cannot usually be used outside the FAST pre-authentication method
 153    since they assume the underlying security layer provided by FAST.
 154
 155    The aim of this draft is to define a new pre-authentication
 156    mechanism, following the recommendations of
 157    [I-D.ietf-krb-wg-preauth-framework], that relies on the GSS-API
 158    security services to pre-authenticate clients.  This pre-
 159    authentication mechanism will allow the KDC to authenticate clients
 160    making use of any current or future GSS mechanism, as long as they
 161    satisfy the minimum security requirements described in this
 162    specification.  The Kerberos client will play the role of the GSS
 163    initiator, while the Authentication Server (AS) in the KDC will play
 164
 165
 166
 167 Perez-Mendez, et al.      Expires March 5, 2013                 [Page 3]
 168 \f
 169 Internet-Draft                 GSS preauth                      Sep 2012
 170
 171
 172    the role of the GSS acceptor.
 173
 174 1.1.  Requirements Language
 175
 176    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 177    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 178    document are to be interpreted as described in RFC 2119 [RFC2119].
 179
 180
 181 2.  Motivation
 182
 183    This work is mainly motivated by the necessity of a way to allow the
 184    KDC to make use of the technologies defined in the ABFAB WG to
 185    perform the access control of federated users.  Specifically, the
 186    ABFAB architecture requires relying parties to make use of the GSS-
 187    EAP mechanism to perform authentication.
 188    [I-D.perez-abfab-eap-gss-preauth] defines how GSS-EAP is transported
 189    on top of the GSS pre-authentication mechanism defined in this
 190    document.
 191
 192
 193 3.  Definition of the Kerberos GSS padata
 194
 195    To establish the security context, the GSS-API defines the exchange
 196    of GSS tokens between the initiator and the acceptor.  These tokens,
 197    which contain mechanism-specific information, are completely opaque
 198    to the application.  However, how these tokens are transported
 199    between the initiator and the responder depends on the specific
 200    application.  Since GSS-API is defined as independent of the
 201    underlying communications service, its use does not require to
 202    implement any specific security feature for the transport.  For
 203    instance, tokens could just be sent by means of plain UDP datagrams.
 204    For this reason, security and ordered delivery of information must be
 205    implemented by each specific GSS mechanism (if required).
 206
 207    Therefore, GSS tokens are the atomic piece of information from the
 208    application point of view when using GSS-API, which require a proper
 209    transport between the initiator (Kerberos client) and the acceptor
 210    (AS).  In particular, the proposed GSS-based pre-authentication
 211    mechanism defines a new pre-authentication element (hereafter padata)
 212    called PA-GSS, to transport a generic GSS token from the Kerberos
 213    client to the AS and vice-versa.  This padata also transport state
 214    information required to maintain the KDC stateless (see section
 215    Section 7.
 216
 217        PA-GSS          To be defined (TBD)
 218
 219    A PA-GSS padata element contains the ASN.1 DER encoding of the PA-GSS
 220
 221
 222
 223 Perez-Mendez, et al.      Expires March 5, 2013                 [Page 4]
 224 \f
 225 Internet-Draft                 GSS preauth                      Sep 2012
 226
 227
 228    structure:
 229
 230        PA-GSS ::= SEQUENCE {
 231           sec-ctx-token [0] OCTET STRING,
 232           state [1] EncryptedData OPTIONAL -- contains PA-GSS-STATE
 233        }
 234
 235        PA-GSS-STATE ::= SEQUENCE {
 236           timestamp [0] KerberosTime,
 237           exported-sec-ctx-token [1] OCTET STRING,
 238           ...
 239        }
 240
 241    The sec-ctx-token element of the PA-GSS structure contains the
 242    output_token token returned by either, the GSS_Init_sec_context and
 243    the GSS_Accept_sec_context calls.  The state element of the PA-GSS
 244    structure is optional, and will be absent in the first AS_REQ message
 245    from the client to the KDC and in the last AS_REP message from the
 246    KDC to the client.  It contains a PA-GSS-STATE structure encrypted
 247    with the first krbtgt key and a key usage in the 512-1023 range (to
 248    be defined TBD).  The state element is generated by the KDC, while
 249    the client just copy it from the previously received PA-GSS structure
 250    (if present).
 251
 252    The PA-GSS-STATE contains a timestamp element, meant to detect
 253    possible replay situations, and a exported-sec-ctx-token element,
 254    representing the whole GSS security context state corresponding to
 255    the current authentication process.  This value is generated by the
 256    KDC by calling to the GSS_Export_sec_context, when the
 257    GSS_Accept_sec_context returns GSS_S_CONTINUE_NEEDED.
 258
 259
 260 4.  GSS Pre-authentication Operation
 261
 262 4.1.  Generation of GSS preauth requests
 263
 264    The Kerberos client (initiator) starts by calling to the
 265    GSS_Init_sec_context function.  In the first call to this function,
 266    the client provides GSS_C_NO_CTX as the value of the context_handle
 267    and NULL as the input_token, given that no context has been initiated
 268    yet.  When using multi round-trip GSS mechanisms, in subsequent calls
 269    to this routine the client will use both, the context_handle value
 270    obtained after the first call, and the input_token received from the
 271    KDC.  The mutual_req_flag, replay_det_req_flag and sequence_req_flag
 272    MUST be set, as the GSS token is meant to be tranported over
 273    cleartext channels.
 274
 275    The GSS_Init_sec_context returns a context_handle, an output_token
 276
 277
 278
 279 Perez-Mendez, et al.      Expires March 5, 2013                 [Page 5]
 280 \f
 281 Internet-Draft                 GSS preauth                      Sep 2012
 282
 283
 284    and a status value.  In this first call, the only acceptable status
 285    value is GSS_S_CONTINUE_NEEDED, as the KDC is expected to provide a
 286    token in order to continue with the context establishment process.
 287    The Kerberos client creates a new PA-GSS padata, with the obtained
 288    output_token as the sec-ctx-token element, and with the state element
 289    absent.  The PA-GSS padata is sent to the KDC through a KRB_AS_REQ
 290    message.
 291
 292 4.2.  Processing of GSS preauth requests
 293
 294    When the KDC (GSS acceptor) receives a KRB_AS_REQ message containing
 295    a PA-GSS padata, but a state element (see Section 7) is not included,
 296    the KDC assumes that this is the first message of a context
 297    establishment, and thus GSS_C_NO_CTX is used as context_handle to
 298    invoke the GSS_Accept_sec_context routine.  Conversely, if a state
 299    element is included, the KDC assumes that this message is part an
 300    ongoing authentication and the value of the state element is
 301    decrypted and used to recover the state of the authentication (see
 302    Section 7).  In both cases, after receiving the message, the KDC
 303    calls to the GSS_Accept_sec_context function, using the adequate
 304    context_handle value and using the received token in the PA-GSS
 305    padata as input_token.
 306
 307    Once the execution of the GSS_Accept_sec_context function is
 308    completed, the KDC obtains a context_handle, an output_token that
 309    MUST be sent to the initiator in order to continue with the
 310    authentication process, and a status value.  If the obtained status
 311    is GSS_S_COMPLETE, the client is considered authenticated.  If the
 312    status is GSS_S_CONTINUE_NEEDED, further information is required to
 313    complete the process.
 314
 315 4.3.  Generation of GSS preauth responses
 316
 317    Once the KDC has processed the input_token provided by the client (as
 318    described in Section 4.2), two main different situations may occur
 319    depending on the status value.  If the client is successfully
 320    authenticated (GSS_S_COMPLETE), the KDC will reply to the client with
 321    a KRB_AS_REP message.  This message will transport the final
 322    output_token in a PA-GSS padata type.  This PA-GSS padata will not
 323    contain the state element.  The reply key used to encrypt the enc-
 324    part field of the KRB_AS_REP message is derived from the GSS security
 325    context cryptographic material.  Section 6 provides further details
 326    regarding this derivation.  At this moment, the KDC also verifies
 327    that the cname provided in the AS_REQ matches the src_name obtained
 328    through the final GSS_Accept_sec_ctx call (except when WELLKNOWN/
 329    FEDERATED is used as cname Section 8).
 330
 331    On the contrary, if further data is required to complete the
 332
 333
 334
 335 Perez-Mendez, et al.      Expires March 5, 2013                 [Page 6]
 336 \f
 337 Internet-Draft                 GSS preauth                      Sep 2012
 338
 339
 340    establishment process (GSS_S_CONTINUE_NEEDED), the KDC will reply to
 341    the client with a KDC_ERR_MORE_PREAUTH_DATA_REQUIRED error message
 342    [I-D.ietf-krb-wg-preauth-framework].  In the e-data field of the
 343    message, the KDC will include the PA-GSS padata, containing both, the
 344    GSS token (sec-ctx-token) and the exported GSS security context
 345    (state) (see Section 7).
 346
 347 4.4.  Processing of GSS preauth responses
 348
 349    When the client receives a KDC_ERR_MORE_PREAUTH_DATA_REQUIRED error,
 350    it extracts the token from the PA-GSS element and invokes the
 351    GSS_Init_sec_context function, as described in section Section 4.1.
 352    If present, the state element of the PA-GSS padata is treated as an
 353    opaque element, and it is simply copied and included into the
 354    generated PA-GSS element without further processing.
 355
 356    On the other hand, when the client receives a KRB_AS_REP, it knows
 357    the context establishment has finalized successfully.  The client
 358    invokes the GSS_Init_sec_context function using the transported GSS
 359    token.  Note that, to be consistent, this call MUST return
 360    GSS_S_COMPLETE and not generate any output_token, since the KDC does
 361    not expect further data from the client.
 362
 363    If the context establishment is completed correctly, the client MUST
 364    use the same key derivation process followed by the KDC (Section 4.3)
 365    to obtain the reply key to decrypt the enc-part of the KRB_AS_REP.
 366
 367
 368 5.  Data in the KDC_ERR_PREAUTH_REQUIRED
 369
 370    When the KDC sends a KDC_ERR_PREAUTH_REQUIRED error to the client, it
 371    includes a sequence of padata, each corresponding to an acceptable
 372    pre-authentication method.  Optionally, these padata elements contain
 373    data valuable for the client to configure the selected mechanism.
 374    The data to be included in the padata for this message is described
 375    in this section.
 376
 377    TBD.  (For example, list of the OIDs of the GSS mechanisms supported
 378    by the KDC)
 379
 380
 381 6.  Derivation of the reply key from the GSS context
 382
 383    The GSS pre-authentication mechanism proposed in this draft provides
 384    the "Replacing-reply-key" facility
 385    [I-D.ietf-krb-wg-preauth-framework].
 386
 387    After a successful authentication, client and KDC may decide to
 388
 389
 390
 391 Perez-Mendez, et al.      Expires March 5, 2013                 [Page 7]
 392 \f
 393 Internet-Draft                 GSS preauth                      Sep 2012
 394
 395
 396    completely replace the reply key used to encrypt the KRB_AS_REP by a
 397    new one that is cryptographically independent from the client's
 398    password stored in client password on the Kerberos users database.
 399    This additional keying material can be obtained by means of calls to
 400    the GSS_Pseudo_random [RFC4401] function, using "KRB-GSS" as the
 401    prf_in parameter.
 402
 403
 404 7.  KDC state management
 405
 406    The Kerberos standard [RFC4120] defines the KDC as a stateless
 407    entity.  This means that, if the GSS mechanism requires more than one
 408    round-trip, the client MUST provide enough data to the KDC in the
 409    following interactions to allow recovering the complete state of the
 410    ongoing authentication.  This is specially relevant when the client
 411    switches from one KDC to different one (within the same realm) during
 412    a pre-authentication process.  This second KDC must be able to
 413    continue with the process in a seamless way.
 414
 415    The GSS-API manages the so-called security contexts.  They represent
 416    the whole context of an authentication, including all the state and
 417    relevant data of the ongoing security context.  Thus, this
 418    information MUST be serialized and sent to the client in order to
 419    ensure that the KDC receiving it will be able to reconstruct the
 420    associated state.  In order to prevent attacks, this information must
 421    be confidentiality and integrity protected using a key shared amongst
 422    all the KDCs deployed in the realm, and must be sent along with a
 423    timestamp to prevent replay attacks.  How this information is encoded
 424    is described in section Section 3.
 425
 426    To generate the serialized security context information, the
 427    GSS_Export_sec_ctx() call is used.  The main drawback of this
 428    approach is that the current GSS-API specifications does not allow
 429    the exportation of a security context which has not been completely
 430    established.  Nevertheless, some GSS mechanisms do allow the
 431    exportation of partially established context (e.g.
 432    [I-D.ietf-abfab-gss-eap]), and we expect that other GSS mechanisms
 433    will do the same in the future.
 434
 435
 436 8.  Support for federated users
 437
 438    This draft supports the authentication of users belonging to a
 439    different domain than the authenticating KDC.  This is achieved by
 440    letting the GSS-API to provide both, the client name and the reply
 441    key to be used.  That means that the requested username may not be
 442    present in the KDC's database.  To avoid the generation of an error
 443    of type KDC_ERR_C_PRINCIPAL_UNKNOWN, when the Kerberos client knows
 444
 445
 446
 447 Perez-Mendez, et al.      Expires March 5, 2013                 [Page 8]
 448 \f
 449 Internet-Draft                 GSS preauth                      Sep 2012
 450
 451
 452    it is operating in a federated environment, it MUST set the value of
 453    the cname field of the KRB_AS_REQ message to a new wellknown value,
 454    WELLKNOWN/FEDERATED, following the model proposed in [RFC6111].  In
 455    this way, the KDC will be completely authenticated by the GSS-API
 456    calls, and thus no local verification of credentials should be done.
 457
 458
 459 9.  GSS channel bindings
 460
 461    In order to link the GSS authentication with the actual Kerberos
 462    exchange transporting GSS tokens, the DER-encoded KDC-REQ-BODY from
 463    the AS-REQ is used as channel bindings.
 464
 465
 466 10.  Acknowledgements
 467
 468    This work is supported by the project MULTIGIGABIT EUROPEAN ACADEMIC
 469    NETWORK (FP7-INFRASTRUCTURES-2009-1).  It is also funded by a Seneca
 470    Foundation grant from the Human Resources Researching Training
 471    Program 2007.  Authors finally thank the Funding Program for Research
 472    Groups of Excellence with code 04552/GERM/06 granted by the Fundacion
 473    Seneca.
 474
 475
 476 11.  Security Considerations
 477
 478    Protection of Request/Responses with FAST, restriction on GSS
 479    mechanism, etc.  TBD.
 480
 481
 482 12.  IANA Considerations
 483
 484    This document has no actions for IANA.
 485
 486
 487 13.  Normative References
 488
 489    [I-D.ietf-abfab-gss-eap]
 490               Hartman, S. and J. Howlett, "A GSS-API Mechanism for the
 491               Extensible Authentication Protocol",
 492               draft-ietf-abfab-gss-eap-09 (work in progress),
 493               August 2012.
 494
 495    [I-D.ietf-krb-wg-preauth-framework]
 496               Hartman, S. and L. Zhu, "A Generalized Framework for
 497               Kerberos Pre-Authentication",
 498               draft-ietf-krb-wg-preauth-framework-17 (work in progress),
 499               June 2010.
 500
 501
 502
 503 Perez-Mendez, et al.      Expires March 5, 2013                 [Page 9]
 504 \f
 505 Internet-Draft                 GSS preauth                      Sep 2012
 506
 507
 508    [I-D.perez-abfab-eap-gss-preauth]
 509               Perez-Mendez, A., Lopez, R., Pereniguez-Garcia, F., and G.
 510               Lopez-Millan, "GSS-EAP pre-authentication for Kerberos",
 511               draft-perez-abfab-eap-gss-preauth-01 (work in progress),
 512               March 2012.
 513
 514    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
 515               Requirement Levels", BCP 14, RFC 2119, March 1997.
 516
 517    [RFC2743]  Linn, J., "Generic Security Service Application Program
 518               Interface Version 2, Update 1", RFC 2743, January 2000.
 519
 520    [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
 521               Kerberos Network Authentication Service (V5)", RFC 4120,
 522               July 2005.
 523
 524    [RFC4401]  Williams, N., "A Pseudo-Random Function (PRF) API
 525               Extension for the Generic Security Service Application
 526               Program Interface (GSS-API)", RFC 4401, February 2006.
 527
 528    [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial
 529               Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
 530
 531    [RFC6111]  Zhu, L., "Additional Kerberos Naming Constraints",
 532               RFC 6111, April 2011.
 533
 534
 535 Authors' Addresses
 536
 537    Alejandro Perez-Mendez (Ed.)
 538    University of Murcia
 539    Campus de Espinardo S/N, Faculty of Computer Science
 540    Murcia,   30100
 541    Spain
 542
 543    Phone: +34 868 88 46 44
 544    Email: alex@um.es
 545
 546
 547    Rafa Marin-Lopez
 548    University of Murcia
 549    Campus de Espinardo S/N, Faculty of Computer Science
 550    Murcia,   30100
 551    Spain
 552
 553    Phone: +34 868 88 85 01
 554    Email: rafa@um.es
 555
 556
 557
 558
 559 Perez-Mendez, et al.      Expires March 5, 2013                [Page 10]
 560 \f
 561 Internet-Draft                 GSS preauth                      Sep 2012
 562
 563
 564    Fernando Pereniguez-Garcia
 565    University of Murcia
 566    Campus de Espinardo S/N, Faculty of Computer Science
 567    Murcia,   30100
 568    Spain
 569
 570    Phone: +34 868 88 78 82
 571    Email: pereniguez@um.es
 572
 573
 574    Gabriel Lopez-Millan
 575    University of Murcia
 576    Campus de Espinardo S/N, Faculty of Computer Science
 577    Murcia,   30100
 578    Spain
 579
 580    Phone: +34 868 88 85 04
 581    Email: gabilm@um.es
 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 Perez-Mendez, et al.      Expires March 5, 2013                [Page 11]
 616 \f