Loading ...
Sorry, an error occurred while loading the content.

ticket based authentication

Expand Messages
  • James G Smith
    I think I recall some mention that security related issues were not being dealt with by this group, but then I saw the RFC for Basic and Digest Access
    Message 1 of 9 , Aug 2, 2000
    • 0 Attachment
      I think I recall some mention that security related issues were
      not being dealt with by this group, but then I saw the RFC for
      Basic and Digest Access Authentication among this groups RFCs...

      If this has been answered already, then a gentle reminder of
      where I need to look will be sufficient :P

      +---
      |
      | I would like to propose an extension to the HTTP standard to
      include yet another authentication scheme. This would allow for
      clients to use a third-party URL (third party being not the
      client and not the site requiring authentication) to generate the
      authentication credentials.

      This would allow for one site to know who someone is without
      having access to the information which would prove their
      identity. This requires that the site requiring authentication
      trust the site issuing the credentials.

      This allows for a central authority to issue credentials without
      untrusted sites having sufficient information to reproduce those
      credentials. This can be important when the identity of the
      untrusted sites may be unknown, or when the information used to
      authenticate to the central authority may be legally protected.

      This scheme also solves the problem with POST requests and other
      requests with a body when trying to implement this scheme with
      the current standards (cookies and redirects) and with finite
      credential lifetimes. With the client unaware of the overall
      process, the user experience is severly affected.

      I believe this can be done within the present framework outlined
      in RFC 2617.

      The auth-scheme would be "ticket" or "third-party" or some other
      sensical tag. The auth-param would be `realm' as presently
      defined. Any parameters required by the site issuing the
      credentials would be included in the URL for that site (see next
      paragraph).

      In addition to the challange, a location header would need to be
      sent so the client knows where to go to obtain the credentials.
      The client would need to not retry the request requiring the
      credentials until it has obtained those credentials from
      following the actions at that location.

      Any request for credentials with this scheme should preempt any
      other request for credentials with this same scheme. This allows
      a client to only track one such request at a time, without
      requiring an unbounded stack of nested requests, or even
      unrelated requests. This also allows for the third-party site to
      use any other authentication scheme it might find necessary
      before issuing the credentials.

      The third-party may issue the credentials in the response header
      with the `Authorization' header line. The client should be able
      to use the contents of this header line verbatim in retrying the
      | original request.
      |
      +--

      This is a bit rough in the description, but if there are any questions,
      let me know. If this is something worthwhile, I'll put together a more
      formal description.
      --
      James Smith <JGSmith@...>, 409-862-3725
      Texas A&M CIS Operating Systems Group, Unix
    • Life is hard, and then you die
      ... [snip] Isn t the algorithm=MD5-sess in Digest auth sufficient? The A1 is basically your ticket. Or maybe I m missing something. Cheers, Ronald
      Message 2 of 9 , Aug 2, 2000
      • 0 Attachment
        On Wed, Aug 02, 2000 at 09:34:07AM -0500, James G Smith wrote:
        > I think I recall some mention that security related issues were
        > not being dealt with by this group, but then I saw the RFC for
        > Basic and Digest Access Authentication among this groups RFCs...
        >
        > If this has been answered already, then a gentle reminder of
        > where I need to look will be sufficient :P
        >
        > +---
        > |
        > | I would like to propose an extension to the HTTP standard to
        > include yet another authentication scheme. This would allow for
        > clients to use a third-party URL (third party being not the
        > client and not the site requiring authentication) to generate the
        > authentication credentials.
        [snip]

        Isn't the algorithm=MD5-sess in Digest auth sufficient? The A1 is
        basically your ticket. Or maybe I'm missing something.


        Cheers,

        Ronald
      • Scott Lawrence
        ... No, Digest as currently defined allows the http server to consult a third party authentication server in order to obtain the secret (but does not specify
        Message 3 of 9 , Aug 2, 2000
        • 0 Attachment
          > From: ronald@...

          > Isn't the algorithm=MD5-sess in Digest auth sufficient? The A1 is
          > basically your ticket. Or maybe I'm missing something.

          No, Digest as currently defined allows the http server to consult a
          third party authentication server in order to obtain the secret (but
          does not specify how that should be done). It does not, however, meet
          the need described here - that the http server be able to instruct the
          client to first obtain credentials through the third party server.

          --
          Scott Lawrence
        • Joris Dobbelsteen
          You might look at Kerberos. Maybe this already provides what you want to have in the authentication. However there needs to come a standard describing how to
          Message 4 of 9 , Aug 2, 2000
          • 0 Attachment
            You might look at Kerberos. Maybe this already provides what you want to
            have in the authentication. However there needs to come a standard
            describing how to use Kerberos authentication with HTTP.

            At least I assumed Kerberos also used tickets e.d. Maybe that it needs to be
            a bit modified (e.g. HTTP-Kerberos), because something with certificates (I
            don't know how it all works).....

            Only a suggestion......

            - Joris Dobbelsteen

            > -----Original Message-----
            > From: jgsmith@... [mailto:jgsmith@...]On Behalf Of
            > James G Smith
            > Sent: woensdag 2 augustus 2000 16:34
            > To: http-wg@...
            > Cc: JGSmith@...
            > Subject: ticket based authentication
            >
            >
            > I think I recall some mention that security related issues were
            > not being dealt with by this group, but then I saw the RFC for
            > Basic and Digest Access Authentication among this groups RFCs...
            >
            > If this has been answered already, then a gentle reminder of
            > where I need to look will be sufficient :P
            >
            > +---
            > |
            > | I would like to propose an extension to the HTTP standard to
            > include yet another authentication scheme. This would allow for
            > clients to use a third-party URL (third party being not the
            > client and not the site requiring authentication) to generate the
            > authentication credentials.
            >
            > This would allow for one site to know who someone is without
            > having access to the information which would prove their
            > identity. This requires that the site requiring authentication
            > trust the site issuing the credentials.
            >
            > This allows for a central authority to issue credentials without
            > untrusted sites having sufficient information to reproduce those
            > credentials. This can be important when the identity of the
            > untrusted sites may be unknown, or when the information used to
            > authenticate to the central authority may be legally protected.
            >
            > This scheme also solves the problem with POST requests and other
            > requests with a body when trying to implement this scheme with
            > the current standards (cookies and redirects) and with finite
            > credential lifetimes. With the client unaware of the overall
            > process, the user experience is severly affected.
            >
            > I believe this can be done within the present framework outlined
            > in RFC 2617.
            >
            > The auth-scheme would be "ticket" or "third-party" or some other
            > sensical tag. The auth-param would be `realm' as presently
            > defined. Any parameters required by the site issuing the
            > credentials would be included in the URL for that site (see next
            > paragraph).
            >
            > In addition to the challange, a location header would need to be
            > sent so the client knows where to go to obtain the credentials.
            > The client would need to not retry the request requiring the
            > credentials until it has obtained those credentials from
            > following the actions at that location.
            >
            > Any request for credentials with this scheme should preempt any
            > other request for credentials with this same scheme. This allows
            > a client to only track one such request at a time, without
            > requiring an unbounded stack of nested requests, or even
            > unrelated requests. This also allows for the third-party site to
            > use any other authentication scheme it might find necessary
            > before issuing the credentials.
            >
            > The third-party may issue the credentials in the response header
            > with the `Authorization' header line. The client should be able
            > to use the contents of this header line verbatim in retrying the
            > | original request.
            > |
            > +--
            >
            > This is a bit rough in the description, but if there are any
            > questions,
            > let me know. If this is something worthwhile, I'll put
            > together a more
            > formal description.
            > --
            > James Smith <JGSmith@...>, 409-862-3725
            > Texas A&M CIS Operating Systems Group, Unix
            >
            >
          • James G Smith
            ... This is what I was thinking. However, I was not wanting to put the actual contents of the ticket, or credential, in the standard, becuase that depends on
            Message 5 of 9 , Aug 2, 2000
            • 0 Attachment
              "Joris Dobbelsteen" <joris.dobbelsteen@...> wrote:
              >You might look at Kerberos. Maybe this already provides what you want to
              >have in the authentication. However there needs to come a standard
              >describing how to use Kerberos authentication with HTTP.
              >
              >At least I assumed Kerberos also used tickets e.d. Maybe that it needs to be
              >a bit modified (e.g. HTTP-Kerberos), because something with certificates (I
              >don't know how it all works).....
              >
              >Only a suggestion......

              This is what I was thinking. However, I was not wanting to put the actual
              contents of the ticket, or credential, in the standard, becuase that depends
              on what the credential server and the website (which is requiring the
              credential) would need to agree on. It could be kerberos, but it could also
              be a signed certificate issued by the credential server.

              Basically, I'm looking for a standard that can give a fairly reliable user
              experience while allowing for transport of credentials issued to a client by
              one site to be used at another site, but without cookies and the other messy
              kludges required.

              For example, if the site requiring the authentication requires
              reauthentication in response to a POST (e.g., the credentials have expired),
              that site must buffer the data until the request is retried with possibly a
              GET of some kind and the new credentials. This can lead to DOS attacks on a
              site. By requiring the client to buffer the POST and retry again, we avoid
              that situation and make for a more reliable user experience.

              By avoiding nested authentication attempts of this type, we avoid the same
              buffer problem on the client side.
              --
              James Smith <JGSmith@...>, 979-862-3725
              Texas A&M CIS Operating Systems Group, Unix
            • David W. Morris
              While not commenting directly on the proposal, I would note in my application deployment role ... firewall and application service provider issues make the
              Message 6 of 9 , Aug 2, 2000
              • 0 Attachment
                While not commenting directly on the proposal, I would note in my
                application deployment role ... firewall and application service provider
                issues make the missing function Scott mentions an important capability.

                Thanks,
                Dave Morris

                On Wed, 2 Aug 2000, Scott Lawrence wrote:

                >
                > > From: ronald@...
                >
                > > Isn't the algorithm=MD5-sess in Digest auth sufficient? The A1 is
                > > basically your ticket. Or maybe I'm missing something.
                >
                > No, Digest as currently defined allows the http server to consult a
                > third party authentication server in order to obtain the secret (but
                > does not specify how that should be done). It does not, however, meet
                > the need described here - that the http server be able to instruct the
                > client to first obtain credentials through the third party server.
              • James G Smith
                From the response, it would seem some form of third-party authentication may be desired and useful, but no clear concensus on how best to go about it. I don t
                Message 7 of 9 , Aug 9, 2000
                • 0 Attachment
                  From the response, it would seem some form of third-party
                  authentication may be desired and useful, but no clear concensus
                  on how best to go about it. I don't have an answer to that, but
                  I have put my thoughts together in the form of a draft, which
                  should appear sometime as

                  draft-smith-http-third-party-authentication-00.txt

                  Until it is posted on the IETF site, it is available from my
                  own workstation at

                  http://hex.tamu.edu/drafts/draft-smith-http-third-party-authentication-00.txt

                  I already have a correction for it -- the expiration time should
                  be in GMT (section 2.2).

                  An issue that is not addressed is how to indicate that the client
                  should abandon the authentication process and discard the pending
                  request awaiting credentials. The authentication process MUST
                  indicate one and only one of success or abandonment. When in doubt,
                  the client may abandon the process? This could be the case if
                  the client becomes confused as to what is going on.
                  --
                  James Smith <JGSmith@...>, 409-862-3725
                  Texas A&M CIS Operating Systems Group, Unix
                • Peter W
                  ... James, I m glad to see this taking shape. I have a longer note I haven t yet sent, but here are some comments: 1) Privacy concerns. This looks like a
                  Message 8 of 9 , Aug 9, 2000
                  • 0 Attachment
                    At 4:47pm Aug 9, 2000, James G Smith wrote:

                    > I have put my thoughts together in the form of a draft

                    James,

                    I'm glad to see this taking shape. I have a longer note I haven't yet
                    sent, but here are some comments:

                    1) Privacy concerns. This looks like a "nice" alternative to third-party
                    banner-ad and web-bug cookies. Even "better", because 3rd party cookies
                    are only visible to the ad/web-bug server, where this could be used to
                    share the same identifier with the content provider and the
                    "authentication" provider.

                    2) Multiple credentials? E.G., if my content site needs to verufy both
                    that the user is an employee of Acme Products and a US citizen, would my
                    content site simply request one credential, and then the next iff the
                    first was acceptable?

                    3) Section 3.2. The expiration time provided by the authentication server
                    could be ignored by a (deliberately noncompliant) client. If you want to
                    be safe, you want a signed credential that includes an expiration time.

                    4) Nit pick. I'd suggest using example.(org|com|net) domains as examples.

                    5) Privacy #2: identity discovery. Send an HTML page that references a 1x1
                    pixel image. The URL for that image sends the client an authentication
                    challenge:
                    WWW-Authenticate: Third-Party realm="CIA" url="https://login.cia.gov/"
                    and uses that to see if the user is able/willing to prove their
                    relationship with the US Central Intelligence Agency.

                    6) Auth server needs more info. The client should give the authentication
                    server some reason to go to the trouble of authenticating the client.
                    Authentication can be expensive, so the authentication provider might not
                    want to go to the trouble for unknown sites. This would also allow the
                    auth server to do nice tricks like encrypting the response for that
                    specific content site. It could even send garbage data in case of failure
                    to protect against identity tests.

                    7) Caching credentials/realm. If two different sites want me to
                    authenticate for WallyWorld on tehuti.nowhere.org, how does my client know
                    that it's OK to send the credential obtained for the first site to the
                    second site? I expect (maybe this should be clarified, or maybe I'm
                    dense) that the credential would be resent to any URL on the content site
                    that issues the same realm challenge. But should the client also only
                    provide the credential if the authentication "url" is the same? Should
                    there be a cookie-like path restriction?

                    -Peter

                    --
                    http://www.bastille-linux.org/ : working towards more secure Linux systems
                  • James G Smith
                    ... Good point. We need some way for the client to know that the user should be aware of the authentication request so it isn t silently taking place. The
                    Message 9 of 9 , Aug 10, 2000
                    • 0 Attachment
                      Peter W <peterw@...> wrote:
                      >At 4:47pm Aug 9, 2000, James G Smith wrote:
                      >
                      >> I have put my thoughts together in the form of a draft
                      >
                      >James,
                      >
                      >I'm glad to see this taking shape. I have a longer note I haven't yet
                      >sent, but here are some comments:
                      >
                      >1) Privacy concerns. This looks like a "nice" alternative to third-party
                      >banner-ad and web-bug cookies. Even "better", because 3rd party cookies
                      >are only visible to the ad/web-bug server, where this could be used to
                      >share the same identifier with the content provider and the
                      >"authentication" provider.

                      Good point. We need some way for the client to know that the
                      user should be aware of the authentication request so it isn't
                      silently taking place. The user should have a way to refuse
                      authentication as with Basic and Digest. Of course, refusal with
                      those two is by virtue of the user having to usually enter some
                      information.

                      One important difference between cookies and the credentials in
                      this scheme are that cookies can persist across client invocations.
                      We are explicitly disallowing / discouraging such behavior in
                      the draft.

                      >2) Multiple credentials? E.G., if my content site needs to verufy both
                      >that the user is an employee of Acme Products and a US citizen, would my
                      >content site simply request one credential, and then the next iff the
                      >first was acceptable?

                      I was not thinking so much of authorization but of authentication.
                      The credential would say this person is who they say they are,
                      and no more unless agreed to by the site requiring the credentials
                      and the site providing the credentials prior to the request.

                      Perhaps be able to form a request such as:

                      HTTP/1.1 401 Unauthorized
                      WWW-Authenticate: Third-Party realm="testrealm@...",
                      url="https://tehuti.nowhere.org/authenticate/",
                      ou=acme, c=us

                      The other end might then require that the ou and c fields match
                      in the ldap entry for the person authenticating. Of course,
                      this is not the best example for this situation, but it does
                      illustrate what is possible in the draft.

                      >3) Section 3.2. The expiration time provided by the authentication server
                      >could be ignored by a (deliberately noncompliant) client. If you want to
                      >be safe, you want a signed credential that includes an expiration time.

                      Having implemented something along these lines before with cookies
                      and redirects, I would expect the site issuing the credentials to
                      encode the expiration time in the credentials. The expiration
                      given to the client would be purely advisory on their part.

                      This could be placed in a section for recommended practices in
                      creating credentials.

                      >4) Nit pick. I'd suggest using example.(org|com|net) domains as examples.

                      -nod-

                      >5) Privacy #2: identity discovery. Send an HTML page that references a 1x1
                      >pixel image. The URL for that image sends the client an authentication
                      >challenge:
                      > WWW-Authenticate: Third-Party realm="CIA" url="https://login.cia.gov/"
                      >and uses that to see if the user is able/willing to prove their
                      >relationship with the US Central Intelligence Agency.

                      Good point. We need a good way for the two sites involved to authenticate
                      themselves to each other. The credentials can authenticate the issuer
                      to the requester, but there isn't a good method for the other way around
                      yet that is scalable.

                      One way is to send a signed identifier as part of the request (the
                      WWW-Authenticate header). This requires communication between
                      the issuer and the requesting site `behind the scenes'. If this
                      could be made sufficient, it could be placed in the `recommended
                      practices' section. This could also address the next issue (#6).

                      >6) Auth server needs more info. The client should give the authentication
                      >server some reason to go to the trouble of authenticating the client.
                      >Authentication can be expensive, so the authentication provider might not
                      >want to go to the trouble for unknown sites. This would also allow the
                      >auth server to do nice tricks like encrypting the response for that
                      >specific content site. It could even send garbage data in case of failure
                      >to protect against identity tests.
                      >
                      >7) Caching credentials/realm. If two different sites want me to
                      >authenticate for WallyWorld on tehuti.nowhere.org, how does my client know
                      >that it's OK to send the credential obtained for the first site to the
                      >second site? I expect (maybe this should be clarified, or maybe I'm
                      >dense) that the credential would be resent to any URL on the content site
                      >that issues the same realm challenge. But should the client also only
                      >provide the credential if the authentication "url" is the same? Should
                      >there be a cookie-like path restriction?

                      We do need to be able to specify the scope of the credentials. With
                      Basic and Digest, it's trivial. They are only good on the site which
                      requested them and for the realm. Perhaps a combination of `url' and
                      `realm' could be used. But then we have the issue of sites requesting
                      them when they shouldn't have them...

                      Allowing some scoping rules that cookies have would help here. We
                      can create a system that is no worse than cookies :P That's not
                      all that comforting, but we do have a worst case scenario.

                      When I worked on something similar to this, but with cookies, the
                      credentials would have been passed to any machine in the .tamu.edu
                      domain since that allowed us to have a central server able to
                      issue to any other machine in the TAMU network, it kept machines
                      from outside TAMU from using it, and it would allow people to
                      authenticate once and hop from site to site.
                      --
                      James Smith <JGSmith@...>, 979-862-3725
                      Texas A&M CIS Operating Systems Group, Unix
                    Your message has been successfully submitted and would be delivered to recipients shortly.