Integrerad Windows-autentisering med utökat skydd

Förbättringar har gjorts som påverkar hur integrerad Windows-autentisering hanteras av HttpWebRequestklasserna , HttpListener, SmtpClient, SslStream, NegotiateStreamoch relaterade i System.Net och relaterade namnområden. Stöd har lagts till för utökat skydd för att förbättra säkerheten.

Dessa ändringar kan påverka program som använder dessa klasser för att göra webbförfrågningar och ta emot svar där integrerad Windows-autentisering används. Den här ändringen kan också påverka webbservrar och klientprogram som är konfigurerade för att använda integrerad Windows-autentisering.

Dessa ändringar kan också påverka program som använder dessa klasser för att göra andra typer av begäranden och ta emot svar där integrerad Windows-autentisering används.

Ändringarna för att stödja utökat skydd är endast tillgängliga för program på Windows 7 och Windows Server 2008 R2. De utökade skyddsfunktionerna är inte tillgängliga i tidigare versioner av Windows.

Översikt

Utformningen av integrerad Windows-autentisering gör att vissa svar på autentiseringsuppgifter kan vara universella, vilket innebär att de kan återanvändas eller vidarebefordras. Utmaningssvaren bör minst konstrueras med målspecifik information och helst även med viss kanalspecifik information. Tjänsterna kan sedan ge utökat skydd för att säkerställa att svar på autentiseringsuppgifter innehåller tjänstspecifik information, till exempel ett SPN (Service Principal Name). Med den här informationen i utbytet av autentiseringsuppgifter kan tjänsterna bättre skydda mot skadlig användning av svar på autentiseringsuppgifter som kan ha använts felaktigt.

Den utökade skyddsdesignen är en förbättring av autentiseringsprotokoll som utformats för att minska autentiseringsreläattacker. Det handlar om begreppet kanal- och tjänstbindningsinformation.

De övergripande målen är följande:

  1. Om klienten uppdateras för att stödja det utökade skyddet bör program tillhandahålla en kanalbindnings- och tjänstbindningsinformation till alla autentiseringsprotokoll som stöds. Kanalbindningsinformation kan endast anges när det finns en kanal (TLS) att binda till. Information om tjänstbindning ska alltid anges.

  2. Uppdaterade servrar som är korrekt konfigurerade kan verifiera kanal- och tjänstbindningsinformationen när den finns i klientautentiseringstoken och avvisa autentiseringsförsöket om kanalbindningarna inte matchar. Beroende på distributionsscenariot kan servrar verifiera kanalbindning, tjänstbindning eller båda.

  3. Uppdaterade servrar har möjlighet att acceptera eller avvisa klientbegäranden på nednivå som inte innehåller kanalbindningsinformationen baserat på principen.

Information som används av utökat skydd består av en eller båda av följande två delar:

  1. En kanalbindningstoken eller KBT.

  2. Information om tjänstbindning i form av ett tjänsthuvudnamn eller SPN.

Tjänstbindningsinformation är en indikation på en klients avsikt att autentisera till en viss tjänstslutpunkt. Det kommuniceras från klient till server med följande egenskaper:

  • SPN-värdet måste vara tillgängligt för servern som utför klientautentisering i klartext.

  • Värdet för SPN är offentligt.

  • SPN måste vara kryptografiskt skyddat under överföring så att en man-in-the-middle-attack inte kan infoga, ta bort eller ändra dess värde.

En KBT är en egenskap för den yttre säkra kanalen (till exempel TLS) som används för att koppla (binda) den till en konversation via en inre, klientautentiserad kanal. KBT måste ha följande egenskaper (definieras också av IETF RFC 5056):

  • När det finns en yttre kanal måste värdet för KBT vara en egenskap som identifierar antingen den yttre kanalen eller serverslutpunkten, oberoende av klient- och serversidan av en konversation.

  • Värdet för den KBT som skickas av klienten får inte vara något som en angripare kan påverka.

  • Inga garantier ges om sekretessen för CBT-värdet. Detta innebär dock inte att värdet för tjänstbindningen samt kanalbindningsinformation alltid kan undersökas av någon annan än servern som utför autentisering, eftersom protokollet som transporterar KBT kan kryptera den.

  • KBT måste vara kryptografiskt integritetsskyddad under överföring så att en angripare inte kan infoga, ta bort eller ändra dess värde.

Kanalbindningen utförs genom att klienten överför SPN och KBT till servern på ett manipuleringssäkert sätt. Servern validerar kanalbindningsinformationen i enlighet med principen och avvisar autentiseringsförsök som den inte anser sig ha varit det avsedda målet för. På så sätt blir de två kanalerna kryptografiskt sammankopplade.

För att bevara kompatibiliteten med befintliga klienter och program kan en server konfigureras för att tillåta autentiseringsförsök av klienter som ännu inte stöder utökat skydd. Detta kallas för en "delvis härdad" konfiguration, till skillnad från en "helt härdad" konfiguration.

Flera komponenter i namnrymderna System.Net och System.Net.Security utför integrerad Windows-autentisering för ett anropande program. I det här avsnittet beskrivs ändringar i System.Net komponenter för att lägga till utökat skydd vid användning av integrerad Windows-autentisering.

Utökat skydd stöds för närvarande i Windows 7. En mekanism tillhandahålls så att ett program kan avgöra om operativsystemet stöder utökat skydd.

Ändringar av stöd för utökat skydd

Den autentiseringsprocess som används med integrerad Windows-autentisering, beroende på vilket autentiseringsprotokoll som används, innehåller ofta en utmaning som utfärdas av måldatorn och skickas tillbaka till klientdatorn. Utökat skydd lägger till nya funktioner i den här autentiseringsprocessen

Namnområdet System.Security.Authentication.ExtendedProtection ger stöd för autentisering med utökat skydd för program. Klassen ChannelBinding i det här namnområdet representerar en kanalbindning. Klassen ExtendedProtectionPolicy i det här namnområdet representerar den utökade skyddsprincip som används av servern för att verifiera inkommande klientanslutningar. Andra klassmedlemmar används med utökat skydd.

För serverprogram omfattar dessa klasser följande:

En ExtendedProtectionPolicy som har följande element:

  • En OSSupportsExtendedProtection egenskap som anger om operativsystemet stöder integrerad Windows-autentisering med utökat skydd.

  • Ett PolicyEnforcement värde som anger när den utökade skyddsprincipen ska tillämpas.

  • Ett ProtectionScenario värde som anger distributionsscenariot. Detta påverkar hur utökat skydd kontrolleras.

  • Ett valfritt ServiceNameCollection som innehåller den anpassade SPN-listan som används för att matcha mot det SPN som tillhandahålls av klienten som avsett mål för autentiseringen.

  • Ett valfritt ChannelBinding som innehåller en anpassad kanalbindning som ska användas för validering. Det här scenariot är inte vanligt

Namnområdet System.Security.Authentication.ExtendedProtection.Configuration ger stöd för konfiguration av autentisering med utökat skydd för program.

Ett antal funktionsändringar har gjorts för att stödja utökat skydd i det befintliga System.Net namnområdet. Dessa ändringar omfattar följande:

En funktionsändring gjordes för att stödja utökat skydd för SMTP-klientprogram i det befintliga System.Net.Mail namnområdet:

  • En TargetName egenskap i SmtpClient klassen som representerar DET SPN som ska användas för autentisering när du använder utökat skydd för SMTP-klientprogram.

Ett antal funktionsändringar har gjorts för att stödja utökat skydd i det befintliga System.Net.Security namnområdet. Dessa ändringar omfattar följande:

En SmtpNetworkElement egenskap har lagts till för att stödja konfiguration av utökat skydd för SMTP-klienter i System.Net.Security namnområdet.

Utökat skydd för klientprogram

Utökat skyddsstöd för de flesta klientprogram sker automatiskt. Klasserna HttpWebRequest och SmtpClient stöder utökat skydd när den underliggande versionen av Windows stöder utökat skydd. En HttpWebRequest instans skickar ett SPN som är konstruerat från Uri. Som standard skickar en SmtpClient instans ett SPN som skapats från värdnamnet för SMTP-e-postservern.

För anpassad autentisering kan klientprogram använda HttpWebRequest.EndGetRequestStream(IAsyncResult, TransportContext) metoderna eller HttpWebRequest.GetRequestStream(TransportContext) i HttpWebRequest klassen som gör det möjligt att hämta TransportContext och KBT med hjälp av GetChannelBinding metoden.

SPN som ska användas för integrerad Windows-autentisering och som en HttpWebRequest-instans skickar till en viss tjänst kan åsidosättas genom att ange egenskapen CustomTargetNameDictionary.

Egenskapen TargetName kan användas för att ange ett anpassat SPN som ska användas för integrerad Windows-autentisering för SMTP-anslutningen.

Utökat skydd för serverprogram

HttpListener tillhandahåller automatiskt mekanismer för validering av tjänstbindningar vid http-autentisering.

Det säkraste scenariot är att aktivera utökat skydd för HTTPS:// prefix. I det här fallet anger du HttpListener.ExtendedProtectionPolicy till ett ExtendedProtectionPolicy med PolicyEnforcement inställt på WhenSupported eller Always och ProtectionScenario inställt på TransportSelected. A-värdet WhenSupported sätter HttpListener i delvis härdat läge, medan Always motsvarar fullständigt härdat läge.

I den här konfigurationen när en begäran görs till servern via en yttre säker kanal, efterfrågas den yttre kanalen för en kanalbindning. Den här kanalbindningen skickas till autentiserings-SSPI-anropen, som verifierar att kanalbindningen i autentiseringsbloben matchar. Det finns tre möjliga resultat:

  1. Serverns underliggande operativsystem stöder inte utökat skydd. Begäran kommer inte att exponeras för programmet och ett otillåtet (401) svar returneras till klienten. Ett meddelande loggas till HttpListener spårningskällan som anger orsaken till felet.

  2. SSPI-anropet misslyckas som anger att klienten antingen angav en kanalbindning som inte matchade det förväntade värdet som hämtades från den yttre kanalen eller att klienten inte kunde ange en kanalbindning när den utökade skyddsprincipen på servern konfigurerades för Always. I båda fallen kommer begäran inte att exponeras för programmet och ett otillåtet (401) svar returneras till klienten. Ett meddelande loggas till HttpListener spårningskällan som anger orsaken till felet.

  3. Klienten anger rätt kanalbindning eller tillåts ansluta utan att ange en kanalbindning eftersom den utökade skyddsprincipen på servern har konfigurerats med WhenSupported Begäran returneras till programmet för bearbetning. Ingen kontroll av tjänstnamn utförs automatiskt. Ett program kan välja att utföra en egen validering av tjänstnamn med hjälp av ServiceName egenskapen, men under dessa omständigheter är det redundant.

Om ett program gör sina egna SSPI-anrop för att utföra autentisering baserat på blobar som skickas fram och tillbaka i brödtexten i en HTTP-begäran och vill stödja kanalbindning, måste det hämta den förväntade kanalbindningen från den yttre säkra kanalen med HttpListener för att skicka den till den interna Win32 AcceptSecurityContext-funktionen . Det gör du genom att använda TransportContext-egenskapen och anropa metoden GetChannelBinding för att hämta CBT. Endast slutpunktsbindningar stöds. Om något annat Endpoint anges utlöses en NotSupportedException . Om det underliggande operativsystemet stöder kanalbindning kommer GetChannelBinding-metoden att returnera en ChannelBindingSafeHandle som kapslar in en pekare till en kanalbindning. Denna kanalbindning är lämplig för att skickas till funktionen AcceptSecurityContext som pvBuffer-medlem i en SecBuffer-struktur, vilken skickas i parametern pInput. Egenskapen Size innehåller längden, i byte, på kanalbindningen. Om det underliggande operativsystemet inte stöder kanalbindningar returnerar nullfunktionen .

Ett annat möjligt scenario är att aktivera utökat skydd för HTTP:// prefix när proxyservrar inte används. I det här fallet anger du HttpListener.ExtendedProtectionPolicy till ett ExtendedProtectionPolicy med PolicyEnforcement inställt på WhenSupported eller Always och ProtectionScenario inställt på TransportSelected. A-värdet WhenSupported sätter HttpListener i delvis härdat läge, medan Always motsvarar fullständigt härdat läge.

En standardlista över tillåtna tjänstnamn skapas baserat på de prefix som har registrerats med HttpListener. Den här standardlistan kan granskas via egenskapen DefaultServiceNames . Om den här listan inte är omfattande kan ett program ange en samling med anpassade tjänstnamn i konstruktorn för klassen som ska användas i stället för ExtendedProtectionPolicy standardlistan för tjänstnamn.

I den här konfigurationen, när en begäran görs till servern utan att använda en yttre säker kanal, fortsätter autentiseringen normalt utan någon kontroll av kanalbindningen. Om autentiseringen lyckas efterfrågas kontexten för tjänstnamnet som klienten angav och verifierade mot listan över godkända tjänstnamn. Det finns fyra möjliga resultat:

  1. Serverns underliggande operativsystem stöder inte utökat skydd. Begäran kommer inte att exponeras för programmet och ett otillåtet (401) svar returneras till klienten. Ett meddelande loggas till HttpListener spårningskällan som anger orsaken till felet.

  2. Klientens underliggande operativsystem stöder inte utökat skydd. I konfigurationen WhenSupported lyckas autentiseringsförsöket och begäran returneras till programmet. I konfigurationen Always misslyckas autentiseringsförsöket. Begäran kommer inte att exponeras för programmet och ett otillåtet (401) svar returneras till klienten. Ett meddelande loggas till HttpListener spårningskällan som anger orsaken till felet.

  3. Klientens underliggande operativsystem stöder utökat skydd, men programmet har inte angett någon tjänstbindning. Begäran kommer inte att exponeras för programmet och ett otillåtet (401) svar returneras till klienten. Ett meddelande loggas till HttpListener spårningskällan som anger orsaken till felet.

  4. Klienten angav en tjänstbindning. Tjänstbindningen jämförs med listan över tillåtna tjänstbindningar. Om den matchar returneras begäran till programmet. Annars kommer begäran inte att exponeras för programmet och ett otillåtet (401) svar returneras automatiskt till klienten. Ett meddelande loggas till HttpListener spårningskällan som anger orsaken till felet.

Om den här enkla metoden med hjälp av en lista över tillåtna tjänstnamn är otillräcklig kan ett program tillhandahålla en egen validering av tjänstnamn genom att fråga egenskapen ServiceName . Egenskapen returnerar null i fall 1 och 2 ovan. Om 3 returneras en tom sträng. I fall 4 returneras det tjänstnamn som anges av klienten.

Dessa utökade skyddsfunktioner kan också användas av serverprogram för autentisering med andra typer av begäranden och när betrodda proxyservrar används.

Se även

  • Last updated on