#3 Secure authentication

open
nobody
Repository (26)
5
2003-05-24
2003-05-24
Tim Mann
No

Currently only a couple of insecure authentication
schemes are implemented for the repository. Attached
are some messages from 2000 giving my design sketch of
how Kerberos authentication could be added, plus a 2002
discussion from the vesta-devel mailing list about
other alternatives.

Discussion

  • Tim Mann

    Tim Mann - 2003-05-24

    Kerberos (or GSS-API) and Vesta - go or no go?

     
  • Tim Mann

    Tim Mann - 2003-05-24

    Re: Kerberos (or GSS-API) and Vesta - go or no go? (Ken Schalk)

     
  • Tim Mann

    Tim Mann - 2003-05-24

    Re: Kerberos (or GSS-API) and Vesta - go or no go? (Tim Mann)

     
  • Tim Mann

    Tim Mann - 2003-05-24

    Authentication system (Scott Venier)

     
  • Tim Mann

    Tim Mann - 2003-05-24

    Re: Authentication system (Ken Schalk)

     
  • Tim Mann

    Tim Mann - 2003-05-24

    Logged In: YES
    user_id=95236

    A related issue that comes up in the attached messages is
    the need for delegation in order to do mastership transfer
    and replication. In both these cases, one repository
    contacts another on behalf of the user.

    The mastership transfer protocol is particularly sticky,
    because once it reaches a certain commit point, it is
    persistent even after the driving repository reboots. But in
    authentication systems that support delegation, delegations
    are usually volatile and time out after at most a day or so.
    We can probably change things so that the delegation is no
    longer needed after the commit point, but I will have to
    reacquaint myself with the details of the protocol to be sure.

    What would be ideal is if the need for delegation in the
    underlying authentication system could be eliminated, since
    some systems don't have it and in some it's very limited and
    clunky. Perhaps we could do our own poor-man's delegation
    that's just enough for our needs. (I.e., the user contacts
    both repositories in order to "introduce" the one that's
    acting as his delegate to the other.) I think this idea
    comes up in the attached messages.

     
  • Tim Mann

    Tim Mann - 2003-05-24

    Re: Authentication system (Tim Mann)

     
  • Tim Mann

    Tim Mann - 2003-05-24

    Re: Authentication system (Scott Venier)

     
  • Tim Mann

    Tim Mann - 2003-05-24

    Re: Authentication system (Tim Mann)

     
  • Tim Mann

    Tim Mann - 2003-05-24

    Minor bug in mastership transfer code

     
  • Tim Mann

    Tim Mann - 2003-05-24

    Logged In: YES
    user_id=95236

    I've found a couple more messages about the
    delegation-after-commit issue in the mastership transfer
    protocol. They're the ones with subject "Minor bug in
    mastership transfer code".

     
  • Tim Mann

    Tim Mann - 2003-05-24

    Re: Minor bug in mastership transfer code (Tim Mann)

     
  • Kenneth C. Schalk

    Logged In: YES
    user_id=304837

    Two notes from the old wishlist:

    1. The repository could check that NFS users come from a
    "privileged port" (port number less than 1024). If the
    client machine is running Unix, only root can talk on such a
    port, so this guards against user-space NFS clients lying
    about their uids.

    2. An old hack idea could be revived for authenticating
    global names: We could have Vesta client machines run an
    Identification Protocol server (RFC1413). The
    Identification Protocol lets a client machine find out what
    user owns a specified TCP connection between it and the
    server machine. The answer is returned as a character
    string. (The server demonstrates its own authenticity by
    using a privileged port.) Using this facility, when a new
    SRPC connection is established, the repository could
    determine what user is making the connection, and use this
    to decide whether to believe his claimed identity.

    Idea #1 does seem like a good idea, but is a minor
    improvement at best. Idea #2 seems like a distraction from
    implementing truly secure authentication.

     
  • Kenneth C. Schalk

    Logged In: YES
    user_id=304837

    Someone asked me about Kerberos authentication for the
    repository's NFS interface. (Currently the repository only
    handles AUTH_SYS, aka AUTH_UNIX.) Their organization has a
    policy of requiring that Kerberos authentication be used
    with NFS, so for them the current lack of support for this
    in the repository is an issue.

    I've been doing a little reading, and it looks like the only
    way to use Kerberos v5 withe NFS is using the RPCSEC_GSS
    security flavor, which means using GSS-API. Some of the
    relevant RFCs:

    RFC 2203 : RPCSEC_GSS Protocol Specification

    RFC 2623 : NFS Version 2 and Version 3 Security Issues and
    the NFS Protocol's Use of RPCSEC_GSS and Kerberos
    V5

    RFC 1964 : The Kerberos Version 5 GSS-API Mechanism

    RFC 1508 : Generic Security Service Application Program
    Interface

    Earlier discussion in this tracker entry have centered
    around SRPC authentication for transactions with remote
    clients or peer repositories. We'd mostly discounted
    GSS-API for that purpose, mainly because we thought it
    couldn't find evidence that it provides support for
    delegation. However, for better NFS security, it seems to
    be a necessity.

     

Log in to post a comment.