<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

<head>

  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">

  <title></title>

</head>

<body bgcolor="#ffffff" text="#000000">

<font face="Bitstream Cyberbit">The flags are what the client is

capable of; not what the client wants.<br>

If the flags are not set by the client and the server uses the

functionality <br>

anyway you will lose.<br>

<br>

<br>

Douglas E. Engert wrote:<br>

</font>

<blockquote cite="mid4023C620.1E32AAE6@anl.gov" type="cite">

  <pre wrap=""><font face="Bitstream Cyberbit">

The flags might be what the client appl wants, but the SSPI might be

actually doing both because it only has an enctype that does both. 

So the protection on the packets may be more then the client requested.

So should the acceptor appl be told what the user requested, or what is

actually being used?   

Jeffrey Altman via RT wrote:

</font></pre>

  <blockquote type="cite">

    <pre wrap=""><font face="Bitstream Cyberbit">Microsoft reports that their Kerberos SSPI code is incompatible with MIT

GSSAPI when INTEG or CONF modes are used independent of one another.

1964 states that the INTEG and CONF flags are to indicate the

availability of the modes in the client.  They are not to be set by the

server.

MIT's clients always set both flags which is fine, but we must be

prepared to accept security contexts which only set one of them.

_______________________________________________

krb5-bugs mailing list

<a class="moz-txt-link-abbreviated" href="mailto:krb5-bugs@mit.edu">krb5-bugs@mit.edu</a>

<a class="moz-txt-link-freetext" href="https://mailman.mit.edu/mailman/listinfo/krb5-bugs">https://mailman.mit.edu/mailman/listinfo/krb5-bugs</a>

</font></pre>

  </blockquote>

  <pre wrap=""><!----><font face="Bitstream Cyberbit">

</font></pre>

</blockquote>

</body>

</html>