Default ticket lifetime - Kerberos

This is a discussion on Default ticket lifetime - Kerberos ; jay alvarez writes: > jabberd2 (by just looking at its config file, it > definitely supports ldap, not sure with kerberos) How to do GSSAPI is part of the Jabber protocol, but is not implemented by any of the servers ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 32 of 32

Thread: Default ticket lifetime

  1. Re: Need some tips on kerberizing our ENTIRE network

    jay alvarez writes:

    > jabberd2 (by just looking at its config file, it
    > definitely supports ldap, not sure with kerberos)


    How to do GSSAPI is part of the Jabber protocol, but is not implemented by
    any of the servers or clients so far as I know.

    > Nagios server monitoring(I've heard some discussions
    > regarding its ldap support, not sure with kerberos)


    I'm not sure what aspect of Nagios you're thinking of here.

    > rt3 TTS(also read some ldap support, not sure with
    > kerberos)


    Standard web application problem, see below.

    > email (qmail or postfix) I just bumped into a document
    > saying postfix supports sasl/gssapi, and qmail has a
    > qmail-ldap version but not sure with qmail-kerberos.


    I don't *think* there's a qmail-smtpd that supports GSSAPI authentication,
    but I'm not sure. Your problem here will be more on the client side
    anyway; it's hard to find clients other than Eudora that support GSSAPI
    authentication for SMTP. You can, however, support Kerberos username and
    password over SSL with any server that uses SASL (even though it's ugly
    and ideally you don't want to do that).

    > ssh (I saw its sshd_config and it has an option for
    > kerberos authentication)


    GSSAPI authentication is part of the standard code. Additional patches
    are needed for GSSAPI key exchange.

    > Unix login (I'm also quite sure it supports being
    > kerberized)


    Yes.

    > radius wifi login( ldap support, also not sure with
    > kerberos)


    You can get RADIUS to authenticate the username and password against
    Kerberos fairly easily. Getting the wifi login itself to use Kerberos is
    a lot harder.

    > ftp (although kerberos provides kerberized ftpd, we
    > are currently using ProFTP, no idea if it supports
    > kerberos authentication)


    Probably not, but you're better off going to sftp anyway. Even if you
    have to use a username and password because not all SSH clients do GSSAPI
    (yet), you can send it over an encrypted channel more easily than with the
    various FTP solutions.

    FTP is really an obsolete protocol at this point, as much as it's still in
    use in various places. If you're still running FTP for anything other
    than anonymous FTP (and there, HTTP is more efficient for a lot of cases),
    you want to be seriously thinking about your migration strategy.

    > samba( we are using snap server. Its an appliance
    > which if it doesn't support kerberos, there's no way
    > to tweek it, I guess.)


    Samba definitely supports Kerberos. Kerberos is the native authentication
    method for current versions of Windows.

    > web apps( I've read some docs regarding apache modules
    > for kerberos, some patches for some web browser to
    > support kerberos authentication and also some rfcs
    > which discusses adding kerberos mech to the SSL/TLS
    > protocol.


    There are basically three different ways of doing Kerberos authentication
    to web applications:

    * Prompt for a username and password via HTTP basic auth over SSL and
    authenticate that username and password via Kerberos. Ugly, but
    simple. Apache modules exist.

    * Use some completely separate protocol for doing authentication that
    uses Kerberos under the hood. Examples include WebAuth and Cosign.
    Apache modules exist. IIS support exists for Cosign in a released
    state and WebAuth in a development state.

    * Use SPNEGO, which is basically negotiated GSSAPI over HTTP. Apache
    modules exist, but requires client support. Supported in current
    versions of Firefox, Mozilla, Safari, and IE, with varying degrees
    of configuration and bug workarounds required. Client must have a
    ticket cache to authenticate to the web server, so this method won't
    work for travelling users using kiosk machines, whereas WebAuth and
    Cosign will.

    In all cases, you have to convince the web application to trust Apache's
    ability to authenticate the user rather than doing its own authentication
    against its own username and password database. The amount of work this
    requires varies from none to rewriting the entire application, so you have
    to evaluate each web application independently.

    The worst offenders generally don't support *any* external authentication
    mechanism, including LDAP, and insist on having the usernames and
    passwords in some internal database table.

    > openldap directory( it definitely supports kerberos)


    Yup.

    > My huge problem is, will it be achievable for those
    > services I have mentioned above? IMO, I don't see any
    > sense on kerberizing some of the services while others
    > are still authenticating through ldap, do you?


    No. You really do not want to have two password repositories that you
    have to keep in sync. You *can* get LDAP to refer its authentications to
    Kerberos, but my understanding is that this is not the fastest thing in
    the world to do.

    --
    Russ Allbery (rra@stanford.edu)

  2. Re: Need some tips on kerberizing our ENTIRE network

    When you ask about nagios support are you asking about authentication to
    the nagios interface or monitoring a KDC? If you asking about
    monitoring I have written a plug in for nagios that monitors our KDCs
    here. I am sure I could share.

    Mark

    jay alvarez wrote:

    >Good day,
    >
    > We had a meeting last time regarding the need for a
    >centralized authentication in our agency. Everyone
    >except me, was looking into using an ldap directory. I
    >insist on them that if we were to use ldap for sole
    >authentication purpose, ldap was not designed for it,
    >and we should be considering the use of kerberos
    >instead. But I told them that there is a catch, if we
    >were to use kerberos, we must find a kerberized
    >versions for those network services we wish to use the
    >kerberos authentication. In short, other custom made
    >apps, such as web applications must find a way to know
    >how to interact with kerberos. On the other hand,
    >doing some research of my own, ldap support for
    >popular services seems to be more available than that
    >with kerberos support. At the end of our meeting, we
    >have agreed upon the accounting of our services which
    >requires authentication and finding out if it supports
    >authentication through ldap(since we still need the
    >directory functions of ldap).
    >
    >But my problem is this, I've been reading a lot of
    >discussion regarding the use of kerberos
    >authentication, its stregth against other mechanisms,
    >the whole protocol itself and I'm pretty much
    >convinced that for authentication, kerberos is the
    >only way to go. In short, I'm still looking forward to
    >using kerberos in our network services authentication
    >instead of ldap which leads me to a bigger problem.
    >Will it be achievable for the following services?:
    >
    >jabberd2 (by just looking at its config file, it
    >definitely supports ldap, not sure with kerberos)
    >
    >Nagios server monitoring(I've heard some discussions
    >regarding its ldap support, not sure with kerberos)
    >
    >rt3 TTS(also read some ldap support, not sure with
    >kerberos)
    >
    >email (qmail or postfix) I just bumped into a document
    >saying postfix supports sasl/gssapi, and qmail has a
    >qmail-ldap version but not sure with qmail-kerberos.
    >
    >ssh (I saw its sshd_config and it has an option for
    >kerberos authentication)
    >
    >Unix login (I'm also quite sure it supports being
    >kerberized)
    >
    >radius wifi login( ldap support, also not sure with
    >kerberos)
    >
    >ftp (although kerberos provides kerberized ftpd, we
    >are currently using ProFTP, no idea if it supports
    >kerberos authentication)
    >
    >samba( we are using snap server. Its an appliance
    >which if it doesn't support kerberos, there's no way
    >to tweek it, I guess.)
    >
    >web apps( I've read some docs regarding apache modules
    >for kerberos, some patches for some web browser to
    >support kerberos authentication and also some rfcs
    >which discusses adding kerberos mech to the SSL/TLS
    >protocol.
    >
    >openldap directory( it definitely supports kerberos)
    >
    >Summary of apps that I'm SURE it has kerberos support:
    >postfix
    >ssh
    >unix logins
    >ldap
    >
    >Summary of apps that I'm NOT SURE if it has kerberos
    >support:
    >
    >jabberd2
    >webapps
    >samba(Snap server)
    >radius
    >rt
    >nagios
    >
    >Our bosses relies on best practices most of the time
    >such as using the most widely use email server, ftp,
    >etc. If only I can convince them the ease of having a
    >rock-solid single sign-on environment kerberos has to
    >offer, which I think I can, I'm sure it would be easy
    >to convince them to use other software alternatives if
    >it supports kerberos rather than those popular ones
    >which lacks it.
    >
    >My huge problem is, will it be achievable for those
    >services I have mentioned above? IMO, I don't see any
    >sense on kerberizing some of the services while others
    >are still authenticating through ldap, do you?
    >
    >What do you think?
    >
    >
    >Thanks!
    >-jay
    >
    >
    >
    >
    >
    >
    >
    >
    >
    >
    >__________________________________
    >Yahoo! Mail
    >Stay connected, organized, and protected. Take the tour:
    >http://tour.mail.yahoo.com/mailtour.html
    >
    >________________________________________________
    >Kerberos mailing list Kerberos@mit.edu
    >https://mailman.mit.edu/mailman/listinfo/kerberos
    >
    >


    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  3. Re: Need some tips on kerberizing our ENTIRE network



    --- Mark Campbell wrote:

    > When you ask about nagios support are you asking
    > about authentication to

    I'm referring to nagios authentication of restricted
    pages, but it's more of webserver/browser negotiation
    problem as others have already mentioned.

    > the nagios interface or monitoring a KDC? If you
    > asking about
    > monitoring I have written a plug in for nagios that
    > monitors our KDCs
    > here. I am sure I could share.

    Thanks!
    Your plugin is interesting, I'll be looking forward to
    obtaining it when we already have our kdc configured.


    >
    > Mark
    >
    > jay alvarez wrote:
    >
    > >Good day,
    > >
    > > We had a meeting last time regarding the need for

    > a
    > >centralized authentication in our agency. Everyone
    > >except me, was looking into using an ldap

    > directory. I
    > >insist on them that if we were to use ldap for sole
    > >authentication purpose, ldap was not designed for

    > it,
    > >and we should be considering the use of kerberos
    > >instead. But I told them that there is a catch, if

    > we
    > >were to use kerberos, we must find a kerberized
    > >versions for those network services we wish to use

    > the
    > >kerberos authentication. In short, other custom

    > made
    > >apps, such as web applications must find a way to

    > know
    > >how to interact with kerberos. On the other hand,
    > >doing some research of my own, ldap support for
    > >popular services seems to be more available than

    > that
    > >with kerberos support. At the end of our meeting,

    > we
    > >have agreed upon the accounting of our services

    > which
    > >requires authentication and finding out if it

    > supports
    > >authentication through ldap(since we still need the
    > >directory functions of ldap).
    > >
    > >But my problem is this, I've been reading a lot of
    > >discussion regarding the use of kerberos
    > >authentication, its stregth against other

    > mechanisms,
    > >the whole protocol itself and I'm pretty much
    > >convinced that for authentication, kerberos is the
    > >only way to go. In short, I'm still looking forward

    > to
    > >using kerberos in our network services

    > authentication
    > >instead of ldap which leads me to a bigger problem.
    > >Will it be achievable for the following services?:
    > >
    > >jabberd2 (by just looking at its config file, it
    > >definitely supports ldap, not sure with kerberos)
    > >
    > >Nagios server monitoring(I've heard some

    > discussions
    > >regarding its ldap support, not sure with kerberos)
    > >
    > >rt3 TTS(also read some ldap support, not sure with
    > >kerberos)
    > >
    > >email (qmail or postfix) I just bumped into a

    > document
    > >saying postfix supports sasl/gssapi, and qmail has

    > a
    > >qmail-ldap version but not sure with

    > qmail-kerberos.
    > >
    > >ssh (I saw its sshd_config and it has an option for
    > >kerberos authentication)
    > >
    > >Unix login (I'm also quite sure it supports being
    > >kerberized)
    > >
    > >radius wifi login( ldap support, also not sure with
    > >kerberos)
    > >
    > >ftp (although kerberos provides kerberized ftpd, we
    > >are currently using ProFTP, no idea if it supports
    > >kerberos authentication)
    > >
    > >samba( we are using snap server. Its an appliance
    > >which if it doesn't support kerberos, there's no

    > way
    > >to tweek it, I guess.)
    > >
    > >web apps( I've read some docs regarding apache

    > modules
    > >for kerberos, some patches for some web browser to
    > >support kerberos authentication and also some rfcs
    > >which discusses adding kerberos mech to the SSL/TLS
    > >protocol.
    > >
    > >openldap directory( it definitely supports

    > kerberos)
    > >
    > >Summary of apps that I'm SURE it has kerberos

    > support:
    > >postfix
    > >ssh
    > >unix logins
    > >ldap
    > >
    > >Summary of apps that I'm NOT SURE if it has

    > kerberos
    > >support:
    > >
    > >jabberd2
    > >webapps
    > >samba(Snap server)
    > >radius
    > >rt
    > >nagios
    > >
    > >Our bosses relies on best practices most of the

    > time
    > >such as using the most widely use email server,

    > ftp,
    > >etc. If only I can convince them the ease of having

    > a
    > >rock-solid single sign-on environment kerberos has

    > to
    > >offer, which I think I can, I'm sure it would be

    > easy
    > >to convince them to use other software alternatives

    > if
    > >it supports kerberos rather than those popular ones
    > >which lacks it.
    > >
    > >My huge problem is, will it be achievable for those
    > >services I have mentioned above? IMO, I don't see

    > any
    > >sense on kerberizing some of the services while

    > others
    > >are still authenticating through ldap, do you?
    > >
    > >What do you think?
    > >
    > >
    > >Thanks!
    > >-jay
    > >
    > >
    > >
    > >
    > >
    > >
    > >
    > >
    > >
    > >
    > >__________________________________
    > >Yahoo! Mail
    > >Stay connected, organized, and protected. Take the

    > tour:
    > >http://tour.mail.yahoo.com/mailtour.html
    > >
    > >________________________________________________
    > >Kerberos mailing list Kerberos@mit.edu
    > >https://mailman.mit.edu/mailman/listinfo/kerberos
    > >
    > >

    >
    >





    __________________________________
    Discover Yahoo!
    Find restaurants, movies, travel and more fun for the weekend. Check it out!
    http://discover.yahoo.com/weekend.html

    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  4. Re: Need some tips on kerberizing our ENTIRE network

    jay alvarez writes:
    > --- Mark Campbell wrote:


    >> When you ask about nagios support are you asking
    >> about authentication to


    > I'm referring to nagios authentication of restricted pages, but it's
    > more of webserver/browser negotiation problem as others have already
    > mentioned.


    Oh, that. Nagios trusts Apache's authentication, so you can plug in
    whatever web authentication mechanism you desire; they all work. (The
    problem there is more that Nagios has a fairly poor concept of
    authorization.)

    --
    Russ Allbery (rra@stanford.edu)

  5. Re: Need some tips on kerberizing our ENTIRE network

    On Wed, Jul 06, 2005 at 12:14:29AM -0400, Mark Campbell wrote:
    > When you ask about nagios support are you asking about authentication to
    > the nagios interface or monitoring a KDC? If you asking about
    > monitoring I have written a plug in for nagios that monitors our KDCs
    > here. I am sure I could share.


    I'd be interested... I'm just using the check_proc over nrpe for our KDCs.

    Please do share.

    --
    Phil Dibowitz
    Systems Architect and Administrator
    Enterprise Infrastructure / ISD / USC
    UCC 180 - 213-821-5427


    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.2.3 (GNU/Linux)

    iD8DBQFCy5EC7lkZ1Iyv898RAvd1AKDCVHL5D5O7sfpAm1WLKb YNm0smhgCeNWDP
    hv9nC4igIktHIhZ0kDwmrEk=
    =1xen
    -----END PGP SIGNATURE-----


  6. Re: Need some tips on kerberizing our ENTIRE network

    Em Quarta 06 Julho 2005 00:46, Russ Allbery escreveu:
    > but I'm not sure. Your problem here will be more on the client side
    > anyway; it's hard to find clients other than Eudora that support GSSAPI
    > authentication for SMTP. You can, however, support Kerberos username and


    Kmail from KDE 3.4 supports gssapi via SASL (I already tested that), as does
    evolution from recent gnome versions if I'm not mistaken.
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  7. Re: Need some tips on kerberizing our ENTIRE network

    Quoting Russ Allbery :

    >> email (qmail or postfix) I just bumped into a document
    >> saying postfix supports sasl/gssapi, and qmail has a
    >> qmail-ldap version but not sure with qmail-kerberos.

    >
    > I don't *think* there's a qmail-smtpd that supports GSSAPI authentication,
    > but I'm not sure.


    In theory it should work with the additional QmailLDAP/Controls patch.
    I DID so some very quick tests when I added SASL support to the patch, but
    I never run it for extensive periods...

    > Your problem here will be more on the client side
    > anyway; it's hard to find clients other than Eudora that support GSSAPI
    > authentication for SMTP. You can, however, support Kerberos username and
    > password over SSL with any server that uses SASL (even though it's ugly
    > and ideally you don't want to do that).


    Oh, my patch don't support THAT, only SASL between Qmail and the LDAP server.
    Good idea though. I'll see what I can do...

    > No. You really do not want to have two password repositories that you
    > have to keep in sync. You *can* get LDAP to refer its authentications to
    > Kerberos, but my understanding is that this is not the fastest thing in
    > the world to do.


    It isn't much slower. In theory, a couple of microseconds (depending
    on hardware of course - if you run old crap as i do, it's about half
    to a quarter of a second per bind .
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  8. Re: Need some tips on kerberizing our ENTIRE network

    >I don't *think* there's a qmail-smtpd that supports GSSAPI authentication,
    >but I'm not sure. Your problem here will be more on the client side
    >anyway; it's hard to find clients other than Eudora that support GSSAPI
    >authentication for SMTP. You can, however, support Kerberos username and
    >password over SSL with any server that uses SASL (even though it's ugly
    >and ideally you don't want to do that).


    You can add Mulberry and Apple Mail to the list (I've personally tested both).

    --Ken
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  9. Re: Need some tips on kerberizing our ENTIRE network


    I've been looking into kerberized web applications (and web services,
    in general), and I have to confess, I've come up short on satisfying
    solutions. I thought I'd open the floor to discussion.

    A big part of the problem is HTTP (big surprise -- yet another
    protocol that is being used for purposes for which it was not
    designed). Yes, IIS supports GSS authentication via SPNEGO, but I
    have not been able to decipher whether data protection is offered;
    anecdotal evidence suggests not; I've read commentary on the web to
    this effect, and if you read the mod_auth_krb source code, you'll see
    no reference to gss_wrap or gss_*_mic, so my guess is that all SPNEGO
    is doing is offering SSO authentication. (That seems to be the gist
    of the spec, as well) I'm not entirely sure if mutual auth is
    offered, either, though I suppose technically it's possible to use
    HTTP 401 to establish a mutually authenticated channel. (Anyone know
    if IE/IIS supports this?)

    If mutual auth is supported, then it's feasible to use TLS with
    Diffie-Helman cipher suites. This way, you get data protection using
    ephemeral keys, so the "certificate management" problem basically
    goes away. That seems like less of a hack than using TLS to do
    target authentication, but somehow it's vaguely less satisfying than
    leveraging Kerberos throughout the protocol.

    The OMG seems to have taken Kerberos seriously with CORBA/SECIOP;
    does anyone know if similar attention has been paid to that
    ubiquitous protocol we've all come to know and love, HTTP?

    /Fred

    PS. It seems to me that the industry (read, Microsoft) is more
    inclined to push for Kerberos integration into SOAP (e.g., http://
    msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec/
    html/ws-security-kerberos.asp), which is certainly do-able, albeit
    ridden with a lot of XML baggage.

    On Jul 5, 2005, at 11:46 PM, Russ Allbery wrote:

    > There are basically three different ways of doing Kerberos
    > authentication
    > to web applications:
    >
    > * Prompt for a username and password via HTTP basic auth over SSL and
    > authenticate that username and password via Kerberos. Ugly, but
    > simple. Apache modules exist.
    >
    > * Use some completely separate protocol for doing authentication that
    > uses Kerberos under the hood. Examples include WebAuth and Cosign.
    > Apache modules exist. IIS support exists for Cosign in a released
    > state and WebAuth in a development state.
    >
    > * Use SPNEGO, which is basically negotiated GSSAPI over HTTP. Apache
    > modules exist, but requires client support. Supported in current
    > versions of Firefox, Mozilla, Safari, and IE, with varying degrees
    > of configuration and bug workarounds required. Client must have a
    > ticket cache to authenticate to the web server, so this method
    > won't
    > work for travelling users using kiosk machines, whereas WebAuth and
    > Cosign will.
    >


    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  10. Re: Need some tips on kerberizing our ENTIRE network

    Fred Dushin wrote:
    > A big part of the problem is HTTP (big surprise -- yet another
    > protocol that is being used for purposes for which it was not
    > designed). Yes, IIS supports GSS authentication via SPNEGO, but I
    > have not been able to decipher whether data protection is offered;
    > anecdotal evidence suggests not; I've read commentary on the web to
    > this effect, and if you read the mod_auth_krb source code, you'll see
    > no reference to gss_wrap or gss_*_mic, so my guess is that all SPNEGO
    > is doing is offering SSO authentication. (That seems to be the gist
    > of the spec, as well) I'm not entirely sure if mutual auth is
    > offered, either, though I suppose technically it's possible to use
    > HTTP 401 to establish a mutually authenticated channel. (Anyone know
    > if IE/IIS supports this?)



    Data protection is not part of the HTTP/Negotiate-Auth protocol. It only
    provides for *authentication* and even that is not protected unless you
    channel it over SSL. After the authentication is complete, GSSAPI is
    never used again for that session. The browsers and servers out there
    today do not support the use of GSSAPI for protecting the HTTP exchanges,
    only SSL.

    Mutual authentication is not supported correctly because it is not possible
    to do so without violating the HTTP spec. Microsoft did it with IIS/IE, but
    Mozilla stops short of the complete mutual-auth checking because it would
    involve alot of hacks in the HTTP engine to handle non-standard fields
    being sent in a "200 OK" response header.

    Basically, the recommended way to do HTTP/GSSAPI authentication
    is to use SSL to protect the exchange and the data. Mozilla/Firefox
    is configured by default to only do the GSSAPI auth exchange if
    the protocol is "https", though that setting can be changed easily
    enough.


    -Wyllys Ingersoll
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  11. HTTP mutual auth [Was: Need some tips on kerberizing our ENTIREnetwork]


    Could you elaborate on how this would break the HTTP spec? I was
    under the (admittedly naive) impression that more or less any
    challenge-response authentication mechanism could be implemented in
    HTTP via the HTTP 401 error code. So presumably I would think that
    GSS context tokens could be exchanged through this mechanism. (E.g.,
    client sends a request with an initial context token, server returns
    an HTTP 401 with a continuation token, client resends request with
    context completion token, and perhaps subsequent requests contain
    some context identifier)

    This approach may not be standard, but a standard authentication
    mechanism could theoretically be proposed. I don't see how it breaks
    HTTP, but I'm not an HTTP expert.

    Thanks,
    Fred

    On Jul 11, 2005, at 12:59 PM, Wyllys Ingersoll wrote:

    > Mutual authentication is not supported correctly because it is not
    > possible
    > to do so without violating the HTTP spec.


    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  12. Re: HTTP mutual auth [Was: Need some tips on kerberizing our ENTIREnetwork]


    I *think* the problem is that Microsoft is returning a "200 OK" message
    but it has
    additional authentication header fields attached to it. If they were
    using the 401
    code, that would be OK, but they are using 200 and adding the final
    mutual-auth
    GSSAPI tokens to it, which, I believe, is a violation. At least that is
    what the Mozilla
    guys told me a while ago when I was working on it.

    -Wyllys


    Fred Dushin wrote:
    >
    > Could you elaborate on how this would break the HTTP spec? I was
    > under the (admittedly naive) impression that more or less any
    > challenge-response authentication mechanism could be implemented in
    > HTTP via the HTTP 401 error code. So presumably I would think that
    > GSS context tokens could be exchanged through this mechanism. (E.g.,
    > client sends a request with an initial context token, server returns
    > an HTTP 401 with a continuation token, client resends request with
    > context completion token, and perhaps subsequent requests contain
    > some context identifier)
    >
    > This approach may not be standard, but a standard authentication
    > mechanism could theoretically be proposed. I don't see how it breaks
    > HTTP, but I'm not an HTTP expert.
    >
    > Thanks, Fred
    >
    > On Jul 11, 2005, at 12:59 PM, Wyllys Ingersoll wrote:
    >
    > > Mutual authentication is not supported correctly because it is not
    > > possible to do so without violating the HTTP spec.



    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


+ Reply to Thread
Page 2 of 2 FirstFirst 1 2